Supersoft Software Solutions

HRAS
System Requirements Specification Document

Version 0.01
Last Revision: 2/8/2011

Adam Chevalier, Ryan DeLuca, Alex Youker

Spring 2011
 Table of Contents

Glossary.............................................................................................................................................1
Introduction.........................................................................................................................................1
Stuff...................................................................................................................................................2

Glossary

HRAS Hospital Record Access System, the product.

GSHA Greater Smogtown area Hospital Association, the client.
SSS Supersoft Software Solutions.
Admin A user with the highest authority within the system.
SQL Standard Query Language. Standard language for communicating with a
database.
Hashing The transformation of plain text to an unintelligible format. Hashing is one-way,
meaning when something is hashed, it cannot be reversed.
Visit A term of stay in the hospital by a patient -- the time between check-in and
check-out.
Algorithm A sequence of steps designed and taken to exactly accomplish a specific task.
Query A query is a message used to communicate with a database.
To query a database is to use a message to cummunicate with a database to
attain information or perform a specific task.
Database A centralized system allowing fast storage and retrieval of information,
relationship hierarchy between data elements, among other [technical] things.
Authorization Level The level of access permissions given to the user based on specification by the
hospital administrator. The level granted to the user restricts or permits the usage
of certain functionalities of the system.

Introduction

This document is provided by SSS to document all intended features and abilities of HRAS,
including those requested by GSHA.

Purpose
 The general purpose of HRAS is to electronically maintain and organize various functions and
tasks performed by GSHA. The HRAS system consists of three levels of user permissions, each of which
grants access to a specific set of functionality.

Overview
User Account types and respective allowed abilities
● Clerks Access to the Inventory Management Subsystem
● Medical Staff Access to the Patient and Inventory Management Subsystems
● Administrator Users of this level have full access to all system functions,
including the authority to add new users to the system and assign access levels. A user
of this level may also be referred to as an “Admin” of the system.

The functionality of the HRAS system can be broken up into these broad categories:

Inventory Management
HRAS maintains a working list of any and all items GSHA requires, both in-stock and out of stock.

An overview of the abilities the Inventory Management grants includes:

● Create/modify/remove categories to organize items within the inventory
● Add new items (not currently in the inventory)
● Edit existing items (name, quantity, re-stock quantity, description)
● Import a shipping list for automated updating of quantities upon receipt of new shipments

Patient Record Management

HRAS allows users with sufficient privileges (permissions defined later in the document) to keep
an electronic record of all patients, present and past.

The Patient Record subsystem allows the following:

● General
○ Create a listing for a new patient in the system
○ Maintain patient information (elaborated upon below)
● Visit related
○ Check a patient in/out (record a patient’s visit to the hospital/mark the
end of the visit)
○ Track various things related to a patient’s visit (elaborated upon below)
○ Viewing of the history of a patient’s visits

Information Maintained:
● Personal information, including SSN, name, height, weight, gender
● Contact information, including address, phone number, and emergency contact
● A history of previous visits to the hospital, with each visit additionally providing:
○ Arrival/Departure (check in/out) date
○ The area/ward of the hospital as well as the room number the patient
resided in during their stay
○ Symptoms observed to bring about reason for the visit, as well as during
the visit
○ Illnesses diagnosed as a result of the visit, if any
○ Supplies/medication/resources used during the visit

Diagnosis Wizard
 The diagnosis wizard allows a user with sufficient privileges to answer a series of questions
regarding patient condition, and after sufficient information is gathered, will suggest probable diagnoses
with respective likelihood of accuracy.

Searching
Though not explicitly mentioned in the individual areas, there is a general search which allows
searching of all information stored within the system, as well as specialized searching capability within the
Inventory and Patient Record subsystems.

Administration Area
The administration area is used to manage user accounts. A system admin can create new
accounts, simultaneously assigning a desired access level. An admin can also modify existing user
accounts, including the user’s access level, or even remove account(s) if desired.

Functionality & User Interface

Log-in Screen
The log-in screen greets the user upon start-up of the program. To access further functionalities
of the system, the user must provide valid system access credentials (user name and password). Upon
clicking the submit button, the log-in information provided by the user will be validated against that stored
in the system. If the user provides valid account information, the user will be brought to the welcome
screen. Otherwise, an error will be displayed and the user will be asked to attempt to log in again.

Figure 1.
Welcome/Navigation Screen
The welcome screen is the user’s portal to the functionality of the system. Four buttons will be
provided to allow the user to choose their course of action: Diagnosis Wizard, Browse/Search, Patient
Records, and Inventory. (Figure 2, Annotation 1.) The user may click on any of these choices to navigate
to the respective functionality provided by the system.
As the user navigates through the system, a history of their previously visited screens will be
tracked. An entry in this history will be added for each proceeding screen the user visits as they branch
away from the welcome screen. The user can therefore navigate backward to a preceding screen easily
without having to navigate to the welcome screen as a starting point. (Figure 2, annotation 2.)
Finally, the ability to log out of the system is also present on the welcome screen, as well as all
proceeding screens. (Figure 2, annotation 3.)

Figure 2.

Browse/Search Subsystem
The browse/search subsystem allows the user to locate the record of an existing patient/inventory
item in the system’s database. Tabs are provided to allow the user to choose the type of search they wish
to perform. (Figure 3, annotation 1.) Search filter options are also provided to allow the user to search the
system based on the criteria of their choice. (Figure 3, annotation 2.) If a user provides invalid search
parameters for a search field, an error message will be generated by the system informing the user of the
proper semantics for the given search field. (For example: “abcde” is used to search while the SSN box
is checked.) If no search results are found, the system will inform the user and suggest using different
search fields.
After a successful search, the user may view extended information related to an item by double
clicking on a result in the table. Upon doing so, they will navigate to a screen relevant to the item they
chose to view. This screen will differ depending on what the user is searching for. (Figure 3, annotation
3.
 Figure 3.

Patient Record Subsystem

The patient record subsystem allows the user to view a specific patient’s record and all of the
information known by the system regarding that patient. (Figure 4, annotation 1.) A pane is provided in
the lower left hand corner of the screen to add additional notes related to the patient during a visit. (Figure
4, annotation 2.) A history of prior visits is also provided which allows a user to select a current or past
visit from a list and view all information regarding said visit. (Figure 4, annotation 3.) From here, the user
can navigate to the Checkout Patient / Compute Bill screen. (Figure 4, annotation 4.)
 Figure 4.

Diagnosis Wizard
The diagnosis wizard will allow the user to provide information about a patient, and formulate a
probable diagnosis based on the information they provide.

A series of questions will be presented to the user, of which the user will be prompted to answer.
The user will choose their answer, and proceed onward until the Diagnosis Wizard reaches an acceptable
conclusion (based on the algorithm covered later in this document), or until one cannot be determined
based on the given input/sample. (Figure 6, annotation 1.)

Buttons are also provided to navigate through questions. A “previous” button can be found near
the bottom-left portion of the screen to allow the user to go to the last answered question. Similarly, a
“next” button is in place to allow the user to navigate to the proceeding question in case they’ve navigated
to a previous question. (Figure 6, annotation 2.) The “next” option provides the same functionality as the
submit button, and neither may be pressed if the currently displayed question is unanswered.
The right hand side of the screen houses a list of possible diagnoses along with respective
calculated probabilities of the diagnoses listed. (Figure 6, annotation 3.) The user will be informed of the
sample size that was used to determine the listed results.
 Figure 6.

Compute Bill / Checkout Patient Screen

The compute bill screen allows the user to view information about the resources used by the
patient as well as the number of days the patient has stayed at the hospital. (Figure 7, annotation 1.) The
system automatically attains this information from the database, and computes the total bill. When the
user clicks the “calculate” button, the program will display a summary of the bill for the user to review.
(Figure 7, annotation 3.)
 Figure 7

Inventory Management Subsystem

The Inventory Management Subsystem allows the user to browse and edit items in the hospital’s
inventory database. Buttons are also provided to allow the user to add, edit and remove an item (Figure
8, annotation 3).
The user can organize items by associating them with user-created categories. Categories can
be added/edited/removed by using the buttons provided (Figure 8, annotation 1). Once the user has
created or chosen an existing category, they may then file items under this category. This then gives the
user the ability to browse items according to their category associations. A drop down menu listing the
categories is provided at the top of the screen which houses an “All Items” entry to allow users to view
items that are categorized or un-categorized. (Figure 8, annotation 2.)
Users may associate an existing inventory item with a category by selecting the item in the list on
the left, selecting the category on the right, and clicking the “assign” button. The item will then be filed
under the category the user chose.
Finally, a user may select “Import order” to import shipping orders that will automatically add the
items included in the shipping order to the system’s inventory database
 Figure 8.

Administration Area
In the administration area, on the left, the user is presented with a field where they can enter a
username and password to create a new user, and select an account access level to associate with the
account. Once the user clicks the submit button, if valid information is provided (a user name and
password of at least a certain size desired by GSHA), the account will be created. This will look similar to
many screens seen previously. (Figure 8.)

To the right, the user will be able to select an existing account for modification. Upon doing so,
they left side fields will be populated with the user’s info.

System Requirements

At this phase, not all system requirements can be addressed. However, the following set of requirements
has been established as a minimum to allow system functionality.

● A computer, acting as a server, to hold and run the main database and server application
for the HRAS system. This computer could be on or off-site, and may or may not need to
be provided/purchased by GSHA for operation.
 ○ If off-site, purchase would most likely not be necessary, and instead be
made usable through a third party hosting company for a monthly
charge.
● Computer workstations with the ability to access a network. The amount and locations of
said workstations are subject to the needs and requirements of GSHA. These
workstations would allow the hospital staff to access to the system.
● A network allowing the communication between the workstations within the hospital and
the server computer, wherever it may reside.

Algorithms

Search
Input
1. searchString
2. criteria[] //to narrow the search
Output
1. items[] //Matching Search Criteria

Algorithm
1. Split searchString on the space character into search[]
2. Generate and execute a SQL query to find records matching any terms within search[],
based on the information attained in criteria[]
3. Generate and populate items[] with the results from the query
4. Return items[]

The search function accepts a search string, with each search term separated by a comma. The
search string is split into individual strings and each is then compared against [stuff] to determine which
field it belongs in. The algorithm then performs a series of SQL queries based on these search criteria.
The results are then used to populate the list box in the corresponding window. If the search string is
invalid, no results will be returned, and the list box will be empty.

Example
User inputs “Adam, Alex, Ryan” and indicates “FNAME” as a criteria. The input is split into an array,
search {“Adam”, “Alex”, “Ryan”}. A SQL Query is constructed to search for matching records. The Query
returns patient records with the following names “Chevalier, Adam”, “Youker, Alex”, and “DeLuca, Ryan”.
The patient records are added to the items[] array. This array is then returned.

Diagnosis Wizard
Input
1. Series of responses to questions determined by the wizard.
2. Possibly a patient record.
Output
1. diagnoses[]
2. probabilities[] //corresponding to diagnoses

Algorithm
If patient data is provided
1. Query the database based on patient data and symptoms
2. Create a list of diagnoses that all returned patients have in common
Otherwise
3. Create a list of all possible diagnoses
4. Sort the list in descending order based on percentage of total patients

Begin Looping
5. Find a symptom which is likely to divide the remaining possible diagnoses as evenly as
possible
6. Present a question to the user asking if the they have the determined symptom
7. Remove all diagnoses from the list which do not exhibit this symptom

If (n*) or fewer possible diagnoses remain, or all remaining diagnoses have at least (p*)
probability
Stop looping and return remaining possible diagnoses
Otherwise
Loop to step 5 and repeat

* Note: these figures are yet to be determined in order to meet the needs of GSHA.

The Diagnosis Wizard begins by asking a series of questions regarding the patient. If the Wizard
was accessed from the main menu it will give the user the opportunity to associate a particular client to
the diagnoses. This will allow the Wizard to use the client’s data to speed up the process. The Wizard
then compiles the data and uses a SQL query to find all patients who have symptoms matching those
determined through questioning. It then calculates the percentage of the total each diagnoses
represents, and displays these in descending order in the Diagnoses Wizard screen.

Example
The user associates a patient named “Doe, John” to the diagnosis. The patient’s data is loaded
into the list of known symptoms (male, 205 lbs., fever, sore throat, etc.). A SQL query is sent out that
asks for all diagnoses which contain at least these symptoms, which returns (“Common Cold”, “Flu”,
“Sickle Cell Anemia”, “Sarcoidosis”). The percentages are then calculated for the symptoms exhibited in
these diagnoses and we sort the list accordingly, (“Head Ache ~ 61.5%”, “Vomiting ~ 18.5%”, “Bruising ~
11%”, “Sharp Abdominal Pain ~ 9%”). Then the user is asked “Does the patient have a headache?”, to
which they respond “No.” Those diagnoses that have the “Head Ache” symptom are removed from the
list, resulting in (“Sicke Cell Anemia”, “Sarcoidosis”). Repeat the sorting by distribution for symptoms,
resulting in (“Bruising ~ 55%”, “Sharp Abdominal Pain ~ 45%”). The user is asked “Does the patient have
bruising?”, to which they respond “Yes.” Remove the diagnoses which do not have the “Bruising”
symptom. The only diagnoses remaining is “Sarcoidosis ~ 100%.” This result is returned.

Security

System Access
The primary method of security in HRAS is password authentication to log in to the system.

Account Restrictions
 User accounts are set up as a multi-level privilege hierarchy. System administrators control
access to the various subsystems by assigning users to a user access level. The specific permissions
associated with each user account type were outlined earlier in the document.

Data Storage
In addition, sensitive user information stored in the database is secured via hashing or
encryption. The specific information chosen to be secured will be at the discretion of GSHA.

Revision History

2/10/2011
● Initial delivery of specification document to the client.

Who is doing what

● Introduction
○ Overview of project's nature, purpose, scope (~1 page)
● Glossary
○ List of technical terms used in the document with very brief definitions or
explanations
■ Any term likely to be unknown to a general audience
■ Any term used in a narrow sense
● Description & User Interface
○ From user's point of view, include all functionality as it will be accessed. :
Navigation Features
■ Include a screenshot or some sort of illustration
● Descriptions of all user types/assumptions including privilege hierarchy
○ Method of authentication
● Details of algorithms used (in middle-ware)
○ Calculations that happen under the hood
○ Include at least one example for each "calculation" area
● Non-functional Requirements (addressed in detail later on; in early stages, only focus on
what we *know*)
○ Things like performance measures
■ Maximum Downtime
■ Speed (in context)
■ Load Assumptions
○ Hardware/Software ?
● "Emergent" System Properties
 ○ Observed when the whole system is operational, not describable in
terms of its parts
● Security
○ Encryption, user account related?, access to machines/data, etc.
● Platform

TODO
1. make sure tenses all agree throughout the document
2. Administrator’s interface for a/e/r user accounts
● Do we allow password recovery? How?

I just thought I’d throw in what notes I have from class into here. It’ll help me when working on
this, and maybe it’ll help you guys as well.

Parts of a System Specification Document

● Introduction
○ Overview of project's nature, purpose, scope (~1 page)
● Glossary
○ List of technical terms used in the document with very brief definitions or
explanations
■ Any term likely to be unknown to a general audience
■ Any term used in a narrow sense
● Description & User Interface
○ From user's point of view, include all functionality as it will be accessed. :
Navigation Features
■ Include a screenshot or some sort of illustration
● Descriptions of all user types/assumptions including privilege hierarchy
○ Method of authentication
● Details of algorithms used (in middle-ware)
○ Calculations that happen under the hood
○ Include at least one example for each "calculation" area
● Non-functional Requirements
○ Things like performance measures
■ Maximum Downtime
 ■ Speed (in context)
■ Load Assumptions
○ Hardware/Software ?
● "Emergent" System Properties
○ Observed when the whole system is operational, not describable in
terms of its parts
● Security
○ Encryption, user account related?, access to machines/data, etc.
● Platform

Guidelines for a Specification Document

● Specify end behavior only, not technical implementation details
● Specify assumptions about input, and ways to handle improper input
● Use enough detail to allow developers to code the actual software
● Remember to write for a general audience as well
○ Project Managers
○ Business Analysts
○ Developers
● Illustrations and examples are a good idea (where appropriate)
● Anticipate the end user's needs and identify "hidden" assumptions about
functionality