Software Requirements Specification (SRS)
EMR-Distribution Project
Authors: Scott Bishop, Edward Messing, Trevor Jelneck, Jeffrey Chapman
Customer: Dr. Lilly Immergluck
Instructor: Professor Betty Cheng
1 Introduction
This document is comprised of seven sections; Introduction, Overall Description,
Specific Requirements, Modeling Requirements, Prototype, References and Point of
Contact. Purpose is the first subsection of the Introduction section and explains the
purpose of this document as well as describes the intended audience. The next subsection
of the Introduction is called Scope and introduces the software product by name;
describes benefits, objectives, goals; and explains what the software generally does.
Definitions, acronyms expansions and abbreviations comprise the following subsection.
Organization is the name for Introduction’s final subsection which presents the structure
of this document and describes the rest of its contents.
The first subsection of Overall Description is termed Product Perspective. It describes the
product’s context, contains a data flow diagram and enumerates constraints. Product
Functions is the next subsection and contains a summary of functions the software will
perform. This is followed by the User Characteristics subsection which covers
expectations about the user such as background and technical skill level. The next
subsection is Constraints and contains descriptions of safety critical properties along with
delineation of properties which when violated prevent the system from functioning
properly. Assumptions and Dependencies is the following subsection’s name which is
comprised of expectations pertaining to software, hardware, environment and user
interactions. The final subsection in Overall Description is called Approportioning of
Requirements and covers requirements determined to be beyond the current project’s
scope.
Specific Requirements gives an enumerated list of product requirements in a hierarchical
structure. These requirements will be the basis upon which the models in the next section
are built.
The next section is titled Modeling Requirements and contains multiple diagrams. The
use case diagrams in this section illustrate how the specific requirements outlined in the
previous section are acted upon by various entities outside of the system. A high level
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)
class diagram depicts the system’s key elements and how data will be represented in it.
Sequence diagrams are utilized to illustrate individual potential system scenarios
involving multiple objects. Finally, state diagram are included to show all the scenarios in
which a single object may be involved.
The Prototype section discusses what functionality is available in the prototype. Its first
subsection, How to Run Prototype, describes just that. The only other subsection in
Prototype is called Sample Scenarios. This subsection showcases a sample scenario using
real data and includes screen captures illustrating what the prototype produces.
The References section provides a list of all documents referenced in this software
requirements specification. Each document’s title, report number, date and publishing
organization are included here. It also includes an entry for the project website.
The seventh and final section of this document is titled Point of Contact and provides
information which any interested parties can use to reach Professor Cheng upon the
project’s completion.
1.1
Purpose
The purpose of this document is to provide a detailed description of the proposed design
for the Atlanta Staph Tracking System (ASTS), a Public Health Surveillance System. It
clearly explains the intended functionality, requirements and constraints of the
aforementioned product. This document is intended for all individuals involved in the
project including customers, developers, users, etc.
1.2
Scope
Though the authors of this document will not be involved in its associated product’s
creation, completing development of what is rigorously described here would result in the
Atlanta Staph Tracking System. The application domain of this software falls under the
classification of a Public Health Surveillance System. The main purpose of this product is
integrating and providing user access to data pertaining to patients with a positive culture
of methicillin resistant Staphylococcus aureus (MRSA) or methicillin sensitive
Staphylococcus aureus (MSSA) who have been treated at any of three Atlanta area
hospitals. This integration has the obvious benefit of a greater pool of information for all
the hospitals to use in diagnosis, research and prevention.
1.3





Definitions, acronyms, and abbreviations
MRSA - Methicillin-Resistant Staphylococcus Aureus
MSSA - Methicillin-Sensitive Staphylococcus Aureus
CA-MRSA – Community Acquired Methicillin-Resistant Staphylococcus Aureus
HA-MRSA – Hospital Acquired Methicillin-Resistant Staphylococcus Aureus
EMR – Electronic Medical Record
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)













1.4
PHSS – Public Health Surveillance System
GIS - Geographic Information System
HL7 – Health Level Seven
GUI – Graphical User Interface
API – Application Programming Interface
HTML - HyperText Markup Language - the predominant markup language for
web pages. It provides a means to create structured documents by denoting
structural semantics for text such as headings, paragraphs, lists etc as well as for
links, quotes, and other items
PHP - PHP: Hypertext Preprocessor - a widely-used general-purpose scripting
language that is especially suited for Web development and can be embedded into
HTML.
SAS - Statistical Analysis Software - refers to statistical software produced by a
company with the same name
SPSS – refers to statistical software produced by a company with the same name
HL7 Standards - Standards for electronic interchange of clinical, financial, and
administrative information among health care oriented computer systems.
Geocoding - Geocoding is the process of finding associated geographic
coordinates (often expressed as latitude and longitude) from other geographic
data, such as street addresses, or zip codes (postal codes). With geographic
coordinates the features can be mapped and entered into Geographic Information
Systems.
SRS – Software Requirements Specification
ASTS – Atlanta Staph Tracking System
Organization
The contents of the remainder of this SRS are briefly described below and ordered as
they will appear.




Overall Description
o Product Perspective – includes data flow diagram, describes product
context and constraints
o Product Functions - summarizes functions the software will perform
o User Characteristics – discusses expectations about user background
o Constraints - descriptions of safety critical properties and those needed for
proper system function
o Assumptions and Dependencies – lists expectations pertaining to software,
hardware, environment and user interactions
o Approportioning of Requirements - covers requirements determined to be
beyond the current project’s scope
Specific Requirements - gives an enumerated list of product requirements
Modeling Requirements – contains use case diagrams, sequence diagrams, a highlevel class diagram and a state diagram
Prototype
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)


o How to Run Prototype – describes what is needed to run the prototype
o Sample Scenarios - showcases a sample scenario using real data
References - provides a list of all documents referenced
Point of Contact - information which any interested parties can use to reach
Professor Cheng upon the project’s completion
2 Overall Description
This section will provide a comprehensive description of ASTS, including a statement of
the overall perspective, the functionality that it will provide, and the expected
characteristics of a typical user. This section also outlines any properties that must not be
violated to ensure the correct operation of the system, any dependencies that will be
assumed to be met, and any functionality that will be considered to be out of the scope of
the system.
2.1
Product Perspective
ASTS is intended to provide an effective means to distribute and disseminate data
regarding Staphylococcal aureus infections between Children’s Healthcare of Atlanta at
Egleston, Hughes Spalding, and Scottish Rite hospitals. The system will not only
aggregate data from all three hospitals in a single location, but also be able to perform
various functions with the collected data such as viewing patient medical records,
exporting data for statistical analysis, geospatial breakdowns of both patient and
bacterium phenotype data, and notification upon vital changes in patient information
regarding Staphylococcal aureus infections.
The system will be built upon the existing systems at all three hospitals. Both Children’s
Healthcare of Atlanta at Egleston and Scottish Rite are currently using the EPIC EMR
system, which allows them to share their information. Hughes Spalding is currently
running a separate, independent system. ASTS will provide a bridge between the EPIC
EMR and the system in place at Hughes Spalding, allowing easy and up-to-date access to
any of the three hospital’s data from any location via a web interface. The following
diagram outlines how the system will interact with all three hospitals and their respective
EMR systems:
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)
ASTS Software
Patient
Record
Patient
Record
Patient
Record
Children’s Healthcare
of Atlanta at Egleston
Scottish Rite
Hughes Spalding
Patient
Data
New Data
New Data
New Data
EPIC
Update
Patient Data
Update
Patient Data
ASTS Database
Update
Patient Data
Updated Record
Patient Record
Updated Record
Updated Record
Egleston
Database
Scottish Rite
Database
Patient Data
Patient
Data
Get Data
from EMRs
Patient Data
Hughes Spalding
Database
This diagram shows the various channels through which different aspects of the system
will interface with each other. A system interface within the ASTS will provide a
connection between the ASTS database and the web application. Additionally, the ASTS
database will interface with existing databases at each of the three hospitals in order to
collect data in a central location. The user interface will be provided through a web
accessible application that authorized users can log into. All major components of the
system (databases, ASTS, hospital users, etc.) will be linked via standard internet
connections.
2.2
Product Functions
The ASTS system will provide the following functionality, as requested in the initial
customer specification document:
1. Integrate access to medical information and laboratory databases from all three
hospitals, providing users with accurate, up-to-date medical records that can be
accessed via a web-based, easy to use GUI.
2. Provide quick and meaningful notifications to hospital staff as patients who have a
history of resistant Staphylococcal infection are admitted to the hospital by
referencing inherent risk factors.
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)
3. Aid hospital staff in recognition and differentiation of Staphylococcal aureus
infections that are resistant to typical anti-staphylococcal treatments (MRSA) and
those that are not (MSSA).
4. Identify and distinguish between Community Acquired (CA) and Hospital Acquired
(HA) Staphylococcal infections based on the amount of time it takes a sample to
develop a positive culture for Staphylococcal aureus.
5. Generate and display “hospital-coded” data to plot all main phenotypes of
Staphylococcal aureus over a map of each hospital to aid hospital staff in locating
areas in hospitals that may be causing a Staphylococcal infection outbreak.
6. Generate and display geo-coded data using ArcView to plot all main phenotypes of
Staphylococcal aureus over the Atlanta area to aid hospital and government staff
isolating and combating Staphylococcal outbreaks within the Atlanta community.
2.3
User Characteristics
The users of the system are expected to be professionals from various areas of the
medical field. It is generally expected that the user has at least a basic understanding of
standard computer operations and web browsing. Users should be reasonably familiar
with Staphylococcal aureus considering that this system is designed to aggregate,
disseminate, and lightly analyze various types of data regarding it.
2.4
Constraints
Given the context of the domain in which ASTS will be used, certain constraints must be
met in order to guarantee patient safety. Although ASTS is not responsible for the
verification or validation of data entered into the EMRs, it shall be responsible for
maintaining the integrity of data already within its boundaries. Timely dissemination of
this data is also vital to an accurate implementation of this system and will take place on
frequent, regular interval. System access will be limited to those users who are authorized
by the hospital in order to maintain proper security of patient information.
Some other constraints exist that while not critical to patient safety must still be met to
ensure correct operation of ASTS. One such constraint is consistent Internet connectivity.
If one or more key system sites are unavailable due to unforeseen network circumstances,
proper operation of the system cannot be guaranteed. If a hardware or other system
failure were to occur at a site, it would also cause the system to enter a potentially
erroneous state.
2.5
Assumptions and Dependencies
It is assumed that our users will have access to a standard web browser (Firefox, Internet
Explorer, Safari, Opera, etc.) with a stable Internet connection. It is also assumed that the
system will be capable of establishing a secure network connection with all hospital
databases to aggregate and disseminate data as required.
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)
Additionally, it is assumed that ASTS will have the hardware and software resources
needed to operate a large-scale web-based system, such as an http server (i.e. Apache
server), a dynamic web scripting language (ie. PHP), and all necessary hardware and
network connections.
2.6
Approportioning of Requirements
While the system will be responsible for aggregation of all EMR data collected between
the three hospitals in a single location, it will be outside the scope of this system to
provide data gathering functionality for the EMR system. ASTS Users will not be able to
edit any previously gathered information regarding patient medical records, infection
information, hospital visits, or other information that is already gathered and managed by
the EMR systems currently in place. Additionally, the verification and validation of all
data entered into EMR systems that ASTS is built upon will be the responsibility of the
EMR gathering the data, not ASTS.
Additionally, ASTS will provide the means to perform statistical analysis on the
aggregated data, but such operations will be performed externally of it. ASTS will be
responsible for exporting the data in format such that common statistical analysis
packages (SAS, SPSS) can read in and operate on it, but such operations will not be
within the scope of ASTS.
Although ASTS will present data in a manner such that users will be able to calculate and
determine the risk factors for a patient to develop a Staphylococcal aureus infection, it
will not be responsible for providing a system to quantitatively determine a patient’s level
of risk given their demographic information and monitoring data.
Finally, it will not be the responsibility of ASTS to obtain patient consent for data
dissemination among the three hospitals. The hospitals will be held responsible for
ensuring this is properly handled.
3 Specific Requirements
1. Provide integrated access to medical information and laboratory databases at all three
hospitals.
1.1. ASTS will establish network connections to each hospital’s database.
1.1.1. ASTS will be granted read access to each hospital’s database.
1.1.2. Data updates will occur on a frequent and fixed time interval of twenty
minutes from each hospital’s database to the ASTS database.
1.2. ASTS will maintain a central database composed of data from each hospital’s
database.
1.2.1. Authorized users from each hospital will be access this data via a webbased GUI.
1.2.2. The central database schema will be designed to enable uniform storage of
data from any of the three hospital EMRs.
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)
2. Provide access to monitoring data as patients who have a history of resistant
Staphylococcal infection are admitted to the hospital.
2.1. Check ASTS database for patient history.
2.1.1. Check patient for previous Staphylococcal infections.
2.1.2. Set flags for efficient monitoring and proper notification if previous
Staphylococcal infections are found.
2.1.3. Determine dates of any previous cultures.
3. Establish services that can identify patients who have developed an infection within
48 hours of their admission to the hospital.
3.1. Determine the specific phenotype of bacterium isolated from the patient
3.1.1. If the isolate resistant to methicillin, oxacillin or other anti-staphylococcal
treatments; it is classified as MRSA.
3.1.2. Otherwise the isolate is classified as MSSA
3.2. Determine the amount of between when a culture sample is taken and when it
becomes positive for Staphylococcal infections.
3.2.1. If the culture becomes positive within 48 hours of sampling, it is classified
as CA-MRSA
3.2.2. If the culture becomes positive beyond 48 hours of sampling, it is
classified as HA-MRSA
4. Offer support for geo-coding of patient information for patients who have had
positive cultures for Staphylococcus aureus and use ArcView to display the data.
4.1. Provide visual representation of Staphylococcus infections over a hospital map.
4.1.1. Differentiate CA and HA infections by color.
4.1.2. Differentiate between MRSA and MSSA infections by color.
4.2. Provide a working geospatial representation of Staphylococcus infections within
the Atlanta area.
4.2.1. Differentiate CA and HA infections by color.
4.2.2. Differentiate between MRSA and MSSA infections by color.
4.3. Identify geospatial trends regarding all types of Staphylococcus infections.
5. Indicate how the system will be compliant with the HL-7 standards.
5.1. ASTS will not incorporate any sensitive data into its database.
5.2. Access to ASTS will controlled by password protected accounts.
4 Modeling Requirements
This section will visually and graphically display various aspects of ASTS from several
perspectives. The Use Case Diagram will outline how the key players in the system
interact with each other when executing tasks that will be frequently performed by the
system. Each specific use case is then broken down and explained in detail, including a
Sequence diagram for each use case that shows how key classes within ASTS interact
over time during the execution of the respective use case. Finally, State diagrams for each
key class are included in order to provide a better understanding of the different states
that the ASTS system can be in at any given time.
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)
4.1
Use Cases and Use Case Diagram
The following is a use case diagram that is meant to represent the primary use cases of
ASTS. After the diagram itself, each use case and its attributes are described in detail
below along with a sequence diagram to represent how the use case would be executed
over time.
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)
Use case - Access Patient Medical Record
Actors:
Users, EPIC/Other databases
Type:
Primary and Essential
Description: User requests patient information and ASTS returns the patient record.
Cross Ref:
Integrated access to patient records
Use cases:
None
Use case - Access Monitoring Data
Actors:
Users, EPIC/Other databases
Type:
Primary and Essential
Description: User can easily track certain patients based on parameter information
Cross Ref:
Providing tracking and monitoring capabilities
Use cases:
Notify Updates
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)
Use case - Notify Updates
Actors:
Users
Type:
Primary and Essential
Description: The ASTS system will notify the users when significant updates have been
made concerning patient information, given the user is tracking those
patients
Cross Ref:
Automated surveillance of patient information
Use cases:
None
Use case - Geospatially Plot Infections
Actors:
Users, EPIC/Other databases, ArcView
Type:
Secondary and Non-Essential
Description: User can request the ASTS to send data to ArcView for geo-coding the
patient data, which gives the user a visual representation of how the
infection is spreading in the community/hospital
Cross Ref:
Support for geo-coding data, as well as determining possible risk factors
Use cases:
None
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)
Use case - Export Data for Statistical Analysis
Actors:
Users, EPIC/Other databases, SPSS/SAS
Type:
Secondary and Non-Essential
Description: User can request the ASTS to export patient data in a format suitable for
its statistical software needs
Cross Ref:
Easy transportation of patient data into statistical software applications
Use cases:
None
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)
4.2
Class Diagram
Below is a complete UML class diagram of the key components of the ASTS system.
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)
4.3
State Diagrams
State diagrams are used to represent all possible states that the system can be in.
Currently, there are no state diagrams for the ASTS.
5 Prototype
The ASTS prototype is intended to showcase all front-end functionality of the ASTS
system without requiring the system to actually be implemented. It will achieve this goal
by creating mock-ups of what potential web pages within our system may look like,
simulating simple workflows, and simulating the plotting of geospatial data.
5.1
How to Run the Prototype
Although a working prototype is still being constructed, a basic explanation of how the
prototype will be operated can be provided. Screenshots of each referenced page or
functionality will be provided at a later date. In order to operate the prototype, a user will
require access to the Internet via a standard web browser (Internet Explorer, Firefox,
Opera, Chrome, etc.). Since ASTS utilizes the client/server style architecture, the
operating system from which the user accesses ASTS will not matter as long as said
operating system can properly run a web browser application.
The first step to accessing the ASTS is to log into the system itself via our login page
(image to be included at a later date) using a staff member’s correct username and
password combination. After logging in, the user has several options: Search for patient
records by various criteria (ie. Name, unique record number, admitted date, etc.), check
to see if a patient being admitted to the hospital has a history of Staphylococcus
infections, view geospatial data pertaining to specific cases or phenotypes of
Staphylococcus, and exporting data from ASTS to a format that can be used by common
statistical analysis software.
The ASTS prototype can be found at the link directly below.
http://www.cse.msu.edu/~cse435/Projects/F09/EMRDistribution/web/repos/Prototype/prototype.html
5.2
Sample Scenarios
The following is a fictional scenario in which ASTS may be used to benefit patients of
hospitals in the Atlanta area:
One afternoon, a father enters the emergency from at Hughes Spalding hospital in
Atlanta, Georiga with his son, who is reporting about a pus-filled sore on his upper
leg. The ER nurse that admitted the patient and the ER doctor on duty both concur
after inspecting the sore that it appears to be caused by a bacterial infection of some
sort. As part of a routine checklist that is performed upon admittance of any patient
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)
with a skin lesion caused by a possible bacterial infection, the nurse accesses ASTS to
help her determine the likelihood of the infection being caused by Staphylococcal
aureus.
After logging into the system, the nurse imitates a search for any patient record in the
ASTS database containing the boy’s name. Upon completion of the search, ASTS
reports that the boy does have a medical record present in the ASTS database, and
that he had been treated for a similar lesion in a similar location a month earlier at
Scottish Rite hospital. ASTS also immediately notified the nurse that the infection
that was treated at Scottish Rite was caused by a strain of CA-MRSA. The nurse
notified the ER doctor on duty, and necessary steps were taken to treat the boy’s
lesion.
Upon admission to the hospital, a sample of bacteria was taken from the boy’s lesion,
and was set to incubate while the boy was being treated in order to confirm exactly
what type of infection was ailing the boy. The culture was checked at fixed time
intervals for a positive reading of MRSA, which first appeared 36 hours after the
sample was taken upon the boy’s admittance to the hospital. Upon entry of this data
into ASTS, the system determined that the boy had once again fallen victim to CAMRSA.
Using the geospatial plotting features provided by ASTS, researchers at Hughes
Spalding located the family’s place of residence in the Atlanta area. Upon viewing the
geospatial data plot, the researchers also noticed a strong cluster of CA-MRSA cases
in the same area as the boy’s place of residence. Upon further investigation, it was
discovered that several children in that area who all attended the same elementary
school had been admitted and treated for MRSA infections. The researchers at
Hughes Spalding notified the regional CDC office, and the school was closed while
the source of the Staphylococcal aureus was located.
6 References
Provide list of all documents referenced in the SRS
Identify each document by title, report number, date, and publishing organization.
Specify the sources from which the references can be obtained.
Include an entry for your project website.
http://www.spss.com/
http://www.sas.com/
Start of your text.
[1]
D. Thakore and S. Biswas, “Routing with Persistent Link Modeling in Intermittently
Connected Wireless Networks,” Proceedings of IEEE Military Communication, Atlantic
City, October 2005.
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)
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)