Software Requirements Specification Final 091211025455 Phpapp02

8/8/2019 Software Requirements Specification Final 091211025455 Phpapp02

1/20

Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have beenmade by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)

1

Software Requirements Specification (SRS)

Project PMR-Droid

Authors: Joe Heldt, Jong Jang, Michael Keesey, Tom Randall, and Kurt Seippel

Customer: Dr. Betty Chengand Dr. Tom Foster, Droid user.

Instructor: Dr. Betty Cheng

1 IntroductionThis Software Requirements Specification document provides an overview of thefunctionality of a Personal Medical Record (PMR) designed for the Motorola Droid phone.

This document will cover the scope, organization, description, constraints, requirements, andthe prototype of the PMR.

1.1 PurposeThe 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 developersand users of the application.

1.2 ScopeThe 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 storedon a central database where health care providers will be able to upload the most recentmedical records for their patients. The application will then be able to download this datafrom the server whenever it needs the up to date medical record.

1.3 Definitions, acronyms, and abbreviationsy Android- The operating system, developed by Google, made to run on cellular

phones.

y Droid- A smart phone that is currently distributed by Verizon Wireless that runs thelatest version of the Android operating system.

y EMR (Electronic Medical Record) - An electronic copy of the patients medicalrecord. Your health care providers provide all information.


2/20


2

y GUI (Graphical User Interface) - The part of the application that the user sees andinteracts with.

y IP Address- A unique number given to every computer on a network to uniquelyidentify it.

y PC (Personal Computer) - A desktop or laptop running the Microsoft windowsoperating system.

y PMR (Personal Medical Record) - A copy of the patients EMR that is stored,accessed and possibly edited by the patient. Contains most, if not all, medical datathat is in your medical record.

y SDK (Software Development Kit) set of tools that makes it possible to createsoftware for a particular piece of software or hardware, in our case the Android 2.0operating system.

y Thumbnail- A scaled down version of an image used to save space but still allow youto preview the image.

y XML (Extensible Markup Language) A widely used type of text data organizationand storage language that use to label and distinguish sections of data orinstructions from each other.

1.4 OrganizationThe 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. Followingthe requirements, there are models describing the application and the description/use of theprototype.

2 Overall DescriptionThis 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.

2.1 Product PerspectiveThis application is specifically designed for the Droid. There needs to be a database with

all of the different patients EMRs for the application to access. The interface will be madeto have a similar look and feel that is consistent with other Droid applications. Most Droidapplications have a similar way to display and navigate through data. The display that will beimplemented by the PMR application will be consistent with other applications. Thisfamiliar GUI will make the user feel more comfortable navigating and viewing the data onour system.


3/20


3

Our PMR system is a part in a larger system. In figure 2.1 you will see that the healthcare worker is in charge of inputted the medical data to make an EMR. Once the EMR ismade, it is stored on a secure database, refer to section 3, which our PMR can access. Onceour application downloads this data, it provides the patient with an organized and easy way tonavigate and view their medical record.

2.2 Product Functionsy Provides a high-level view of the key types of medical information that includes

medications, procedures, vaccinations, conditions, allergies, family history, test and labresults, insurance providers, and emergency contacts.

y Provides a means to easily navigate, using the Droids touch screen interface andkeyboard, to the details of any of the key types of medical information.

y Provides access to different types of media for medical records including images, text-based documents, and scanned documents.

y The user is able to backup a local copy of their PMR on their personal computer and editit. This backup can be later transferred back to the phone if needed.

2.3 User CharacteristicsThe 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 inputthe data. The user will also have to know some basic medical terminology and informationto understand the application and the different categories.

2.4 ConstraintsOne major constraint on the application is the amount of data that can be stored on the

phone. The EMRs on the server can contain large sized files, like images and scanneddocuments. These large files can quickly use up a lot of the space available on the Droid, soour application doesnt save these files stored locally. Instead, a thumbnail is saved on theDroid and the user can choose to download the image if they feel it is important. This willsave space by limiting the amount of images actually stored on the phone.

EMR Database PMR

Figure 2.1

Health Care Provider Patient


4/20


4

One other constraint is that this application will not work on other phones. Thisapplication will only work on the Android 2.0 operating system. The Motorola Droid iscurrently the only phone in production that supports Android 2.0.

2.5 Assumptions and DependenciesAndroid 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, videoand camera, and touch-screen support. Our application will use all of these features andshould 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 uniquebuttons, we will only use these buttons to end the application and rely on the touch screenand keyboard to perform the rest of the applications navigation.

2.6 Approportioningof RequirementsOne 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 andview the PMR. Having a more robust system could offer better navigation, ability to see if afile on the Droid or server has changed, or many other features.

Another feature to be added will be an auto-sync feature. This will automaticallyupdate the PMR on either the Droid or computer whenever the EMR on the server haschanged. 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 functionalityadded to improve the security. Some ways to improve security could be to add somebiometric access, like finger print or iris scanning which is possible using the Droid, but notreliable as of yet.

3 Specific RequirementsThis section provides further details on the specific requirements of our application.

Each requirement is given along with a description of the requirements.

1. Provide a high-level view of the key types of medical information: We will have a frontpage where basic medical data will be displayed. This front page is designed to be usedin 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 pagewithout having to log in. For security reasons, the user can hide whatever informationthey dont want someone to see without logging in. They can go through and selectwhatever information they think is important on the front page, and hide whateverinformation they dont want anyone to see.


5/20


5

2. Provide a means to easily navigate to the details of any major categories: there is a tabbeduser interface where the major topics will be selectable. Once a category is selected, thescreen will be refreshed to a separate page where all the relevant information will bedisplayed in an organized fashion.

3.

Provide access to different types of media for medical records, including:a. Text-based documentsb. Images (CT-scans, X-rays)c. Scanned documentsd. Photographs

All of the above information will be stored on the server unless specificallydownloaded by the user. A persons medical record can contain dozens ofpictures 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 theythink it is important, but dont include it automatically to save space.

4. For each medical procedure, diagnosis, medication prescribed, there will be the followinginformation stored with the entry:

a. A healthcare workers complete contact informationb. Date of eventc. Rationale for treatment/medication/diagnosisd. Follow-up activitiese. As appropriate, any short-term or long-term side effectsf. As appropriate, any relationship to family history (ancestors and/or descendants).

This information is standard for any information provided by in the medicalrecord, other than the basic information. There can be more information neededdepending on the kind or medical information being provided, so wherevernecessary there are more fields to input additional data. Below is a list of thisadditional information:

1. Medication - name, dosage, frequency, date prescribed and date ended.2. Medical procedure - procedure type and date of procedure.3. Vaccination - name and frequency.4. Medical condition name, diagnosis, symptoms, treatment, severity, onset

date, and cured date.5. 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 theallergy.

6. Lab and test results - the type of result, what hospital it was administeredat, the results, and a link to the scanned document.

5. A means for a patient to record information (e.g., symptoms, context, photographs ofcondition): Sometimes the user will want to comment on the different pieces ofinformation in the application. This is possible for any of the information stored on the


6/20


6

phone or computer. Once the user comment on something, it is flagged as Commentedon by User so the users doctor knows that this is not information provided by a doctorbut by the patient. This is important so the doctor knows that all the other data is stillreliable and he can trust that it can from a medical provider. These comments will besynced with the data on the database so whenever the user downloads the latest version of

the data, the user will also get their comments.

6. Be able to backup information onto computer: At any point the user can connect theDroid phone to a computer, or use the computer application to download the data fromthe server directly. Once the medical record is on the computer, it provides a safe backupin the event that something happens to your phone. The PMR on the computer can alsobe synced with the medical record on the server if something is added or changed. If atany point the PMR on the Droid becomes corrupt or lost, the user can download the fileon their computer and save it back to the phone.

7. Security: Some information is more private than the users personal medical history.With this in mind, the system seeks to maintain a high level of security. The securitymeasures are separated into two domains: database/server security, and userauthentication.

a. Database/Serveri. 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 basicinformation like name, address, phone number, etc. The second groupwill contain the more secure data like test results, medical condition,medications, etc. These groups are stored on separate servers, with afirewall in between them, as well as a firewall protecting the system as awhole. This multi-layer firewall approach allows the most sensitive data tobe protected by multiple firewalls.


7/20


7

ii. Direct access to the databases will be restricted by IP to the developersonly. No one else will have direct access to the data.

iii. Commercial anti-virus software will be employed on all servers.iv. Administrator and developer passwords must be changed every 14 days.v. Developers will also use CryptoCard authentication tokens for one-use

randomly generated passwords.

b. UserAuthenticationi. Users, defined as either patients or health care providers, will need to use

username and password authentication to gain access to their data.ii. User passwords will require one or more uppercase letters, one or more

lowercase letters, one or more numerical values, and one or more specialcharacters (@, $, %, etc.).

iii. If no activity within the application is registered for a period of tenminutes, the user will be logged out automatically.

4 Modeling RequirementsTo 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 recordconsists of basic personal information (e.g. name, social security number, gender, bloodtype), insurance information, family history, emergency contacts and zero or more medicalrecord 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

Figure 3.1


8/20


8

the Droid device, and can be downloaded when in network for display or storage. Bothphysicians and patients can upload images or scans to associate with any entry and eachimage will be flagged as being uploaded by either the patient or the doctor. Only the healthcare provider can add or edit entries, but the patient can comment on any entry (see figure4.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 databases records. When the health care provider syncs, they add the new and updatedentries to the server and can update any comments made by the patient. Along with addingany comments made by them, when the patient syncs to the database they also receive theupdated information that the doctor added (see figures 4.3 and 4.4). After syncing, the usercan display the new info on their Droid, though syncing is not necessary when out ofnetwork; the Droid will just display the latest version of the medical record since the lastsync. When displaying an entry, the patient can choose to download any images associatedin 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 xmlencrypted document and will overwrite the previous copy. If any images are still in memorywhen syncing, the patient will have the option of backing those up as well.


9/20


9

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.


10/20


10

System

Figure 4.2: Use Case Diagram. The arrows point to what functions the

atient and the healthcare provider can do within the PMR system.

Health CareProvider

newRecord

Login

Patient

sync

backupInfo

downloadImage

display

Extends

editInfo

uploadImage

Logoff

commentInfo


11/20


11

Fi

re

.

: Seq

e

ce

i

r

f

r t

e

e

lt

re

r

vi

er

se c

ses.

is s

s t

eseq

e ce f eve ts

i ter cti s

et ee t

e

e lt

c re r vi

er

t

er e

ers ft

e

cl ss

i r (fire

.

).

ere, t

e

e t

c re r vi

erl s i , cre tes e tie ts e

ic l rec r

, e

its tie ts e

ic l rec r

,

s i es t t

e

t

se, sy cs t

e i f

ck t t

e

t

se

l s ff.

addEntry()

newRecord()

:Health CareProvider

:Patient :Medical Record :Entry :Basic Info :Computer:Database

editInfo()

addBasicInfo()

editEntry(E)

login()

uploadImage(string filepath)

logoff()

editBasicInfo()

sync()

uploadImage(string filepath)

sync()


12/20


12

:HealthCare

Worker

:Patient :Medical Record :Entry :Basic Info :Computer:Database

login()

logoff()

display()

downloadImage(image i)

commentInfo()commentBasicInfo()

commentEntry()

backupInfo()

sync()

display()

returnImage()

returnXML()

Figure 4.4:

euence Diagram for the Patient use cases. This shows the se

uence 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 animage, comments on an entry, syncs the comment back to the database, backs up the record and

logs out.

sync()


13/20


13

The following diagrams (Figures 4.5 and 4.6) illustrate the behavior of our Patient andHealth Care Provider classes, respectively. The Patient object initially executes the loginfunction when starting the program, and enters the Patient Logged In state upon successfulauthentication. In this state, the Patient automatically executes the sync function, whichupdates the data on the Droid device to match that on the systems database server (and if

there is still unsaved Patient-edited data on the Droid device, uploads that data to thedatabase). The Patient also executes the display function from this state automatically,which displays the data from the Patients 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 twomain ways. First, the Patient can upload an image file and attach it to an entry in the medicalrecord. This happens when the UploadImage function is executed by the user and thePatient enters the Uploading Image state. When the image has finished uploading, thePatient enters the Local Patient Info Changed state. Similarly, from the Patient LoggedIn state, the Patient can make a comment on an entry in the medical record when thecommentInfo function is executed by the user and the Patient enters the Commenting onInfo 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 theLocal Patient Info Changed state, the Patient can execute the sync function to upload thedata back to the database. The Patient can log out of the system from either the PatientLogged In or the Local Patient Info Changed states in the latter, the changed data isstored on the Droid device until the Patient logs in again.

Figure 4.5


14/20


14

Figure 4.6 shows the state diagram for the Health Care Provider class. Initially, theHealth Care Provider logs into the system using the login function and enters the HCProvider Logged In state upon successful authentication. A Health Care Provider can add anew Patient to the system from here by executing the addPatient function from theinterface. The Provider can also display a patients medical record from this state. When a

Provider begins editing the data in a Patients medical record, the EditInfo function isexecuted and the Provider enters the Editing Info state. When the editing is complete, theProvider 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 Logofffunction.

5 PrototypeThe 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 asthe form used by a health care provider. The main functions on the Droid will includedownloading a data file from the server, viewing the file in separate categories, and editingsections of the data file. The application will also include buttons to upload the data files toboth the server and a PC as a backup file. The server side will include a template locatedonline to input information that will generate an XML based file. This file will then bedownloaded by the application on the phone when it is started. The server will also containexample pictures and/or medical documents that will be viewable on the phone.

Figure 4.6


15/20


15

5.1 How to Run PrototypeThe primary way to view this application is to download the Android emulator to your home oroffice computer. Windows, Mac, and Linux systems are all able to access this emulator. You willfind 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 beenrunning on. There are more links under the SDK tab on the android development website thatwill further assist you in downloading and installing the emulator. Source code for thisapplication 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 viewablescreens on the application.

5.2 Sample ScenariosIf 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.

To add information, the doctors will have to simply type in the information. Figure 5.2.2represents input for the basic information such as name and address.

Figure 5.2.1


16/20


16

For basic info, all they need to do is type in the information. However, entries such asmedications or vaccinations, they need to click on Add (Entry name) to add the info to theoutput file. Figure 5.2.3 shows where the button is.

After inputting all the data, doctors will then save the information to a file the server byclicking 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.2

Figure 5.2.3


17/20


17

Since the data was saved in the server, the client will have access to this data. When thepatient first open up the application, the patient will see a screen that looks like Figure 5.2.5.

Since the user did not log in yet, everything but Basic Information and EmergencyContacts will be disabled. To log in and see the patients information, the patient will clickthe Login button. Figure 5.2.6 shows the login screen.

Figure 5.2.4

Figure 5.2.5


18/20


18

After logging in the patient will have complete access to the application. Figure 5.2.7shows the unlocked main screen.

Now the patient wants to see their basic information. All they need to do is click on thebasic information to go to basic information screen. Figure 5.2.8 shows the basic informationscreen.

Figure 5.2.6

Figure 5.2.7


19/20


19

In this case, the patients 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 willclick on Edit button to go to the edit screen shown in Figure 5.2.9.

Figure 5.2.8

Figure 5.2.9


20/20

Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been 20

After changing the name, the user has two options. The first option is to click the buttonReturn with Unchanged Data and have all changes reverted. The second option is to clickthe Done Editing button to change the data as shown in Figure 5.2.10

6 References[1] Download the Android SDK Android Developers 2009 Android

http://developer.android.com/sdk/index.html

[2] CRC. Update on Meaningful Use CRC Healthcare. November 2009

[3] PIH Model Online. EMR Benefits, Challenges and Uses

[4] Ilie, Virginia, Courtney, James, and Slyke, Craig. Paper vs. Electronic: ChallengesAssociated with Physicians Usage of Electronic Medical Records. Hawaii InternationalConference on System Science. 2007

7 Point ofContactFor 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 documenthave been sanitized for proprietary data. The students and the instructor gratefully acknowledgethe participation of our industrial collaborators.

Figure 5.2.10

Documents

Software Requirements Specification Final 091211025455 Phpapp02