software requirements specification - personal websites - office
TRANSCRIPT
Software Requirements Specification
Project Name:
Health Records System at Drexel Convenient Care Center
Company Name: Team 5
Team Members:
Sumanth Nalluru
Anusha Shetty
Fangwu Wei
2010 Team 5
Revision History
Date Revision Description Author
06/06/2010 1.0 Initial Version Sumanth Nalluru
Anusha Shetty
Fangwu Wei
06/09/2010 2.0 Final Version Sumanth Nalluru
Anusha Shetty
Fangwu Wei
Software Requirements Specification Page i
Table of Contents 1. Introduction ................................................................................................................................ 1
1.1 Purpose ............................................................................................................................. 1
1.2. Scope ................................................................................................................................ 1
1.3 References List of project-related references or applicable documents that bear on this
project: ........................................................................................................................................ 1
1.4 Assumptions and Dependencies ....................................................................................... 2
2. Software Product Overview ....................................................................................................... 3
2.1 System Scope ................................................................................................................... 3
2.2 System Architecture ......................................................................................................... 3
2.2.1 External View of Software Product .......................................................................... 3
2.2.2 Internal View of Software Product ........................................................................... 5
2. 3 Feature Overview ................................................................................................................. 6
FEA11: Medication Management ........................................................................................... 7
3. System Use ................................................................................................................................. 8
3.1 Support For User Workflows ................................................................................................ 8
3.2 Actor Survey ......................................................................................................................... 9
3.2 Use-Case Model and System Events .................................................................................. 10
3.2.1 Use-Case Model ........................................................................................................... 10
3.2.2 System Events .............................................................................................................. 11
3. 3 System Interfaces ............................................................................................................... 12
4. Specific requirements ............................................................................................................... 13
4.1 System Use-Cases ............................................................................................................... 13
Use case name............................................................................................................................... 16
Actors ............................................................................................................................................ 16
Brief Description ........................................................................................................................... 16
4.2 System Functional Specification .................................................................................... 26
4.3 System Domain Models ...................................................................................................... 28
4.3.1 Internal Domain Model ........................................................................................... 28
4.3.2 Data Models ............................................................................................................ 28
4.4 Non-Functional Requirements ............................................................................................ 29
4.4.1 Usability .................................................................................................................. 29
4.4.2 Reliability ................................................................................................................ 29
4.4.3 Performance ............................................................................................................ 30
4.4.4 Supportability .......................................................................................................... 30
5. SUPPLEMENTARY REQUIREMENTS ......................................................................... 30
5.1 Project management strategy .............................................................................................. 30
5.2 Systems Security and Audit ................................................................................................ 30
Software Requirements Specification Page ii
5.3 Assumptions and Dependencies ..................................................................................... 31
5.4 Requirements Traceability ............................................................................................. 31
6. Online User Documentation and Help System Requirements ................................................. 33
6.1 Training ............................................................................................................................... 33
6.2 User Documentation ........................................................................................................... 33
6.3 User Support ....................................................................................................................... 33
7. Design Constraints .................................................................................................................... 33
8. Interfaces .................................................................................................................................. 33
8.1 User Interfaces................................................................................................................ 33
8.2 Hardware Interfaces ....................................................................................................... 34
8.3 Software Interfaces ......................................................................................................... 34
8.4 Communications Interfaces ............................................................................................ 34
9. Licensing Requirements ........................................................................................................... 34
10. Applicable Standards ......................................................................................................... 34
Glossary ........................................................................................................................................ 34
APPENDIX ................................................................................................................................... 35
Software Requirements Specification Page 1
1. INTRODUCTION
1.1 Purpose
This document outlines the software requirements for the Electronic Health Record system for
the Drexel Convenient Care Center. It describes the functional and non-functional requirements,
modeling requirements, diagrams and user profiles of the proposed system. The electronic health
record system enables DCCC staff to maintain an electronic health record of a patient who visits
DCCC. It also enables seamless sharing of the patient‟s health record with the Drexel network of
hospitals. This SRS provides detailed information on the internal and external view of the system
as well as interfaces required and provided by the Health record system.
1.2. Scope
The Electronic Health Record (EHR) System for DCCC will facilitate the staff of the DCCC to
have electronic health records of patients. The following will be the main functions of the EHR:
Create, update and view patient‟s electronic health records
Add medical documents, images and scanned copies to patients health record
Able to search for patient‟s from all the Drexel network of hospitals.
Provide referrals to Drexel Specialists
Generate e-prescriptions
The system to be developed will be hosted by Drexel College of Medicine. Terminals and
laptops at DCCC will be able to connect to it using a web service. The data entered and uploaded
will be saved on the data servers. This data will be accessible by all the hospitals in the Drexel
network. If a patient has visited a Drexel hospital earlier, his record will be updated with the
existing conditions and no new record will be created.
This system is a customized version of the AllScripts version which is currently being used by
most departments in the Drexel network of hospitals. This system will not include any billing
feature; it will only provide diagnosis code, which may be used for billing by other systems.
1.3 References
List of project-related references or applicable documents that bear on this project:
Leffingwell, Dean and Widrig, Don (2003) Managing Software Requirements: A Use-
Case Approach, 2nd. Edition, Addison Wesley Longman.
Team #5‟s Project Proposal document: Info627_assignment0_Team5.doc
Info627_Assignment-1_Team5.v2.doc
AllScripts healthcare software website, http://www.allscripts.com/
Monk, A., Howard, S. The rich picture: a tool for reasoning about work context
Notes from Interview with Dr.Chou (Chief Medical Informatics Officer of DUCOM)
Notes from Interview with Kelly (Lead Staff at DCCC)
Notes from Interview with Nancy (Systems Analyst at DUCOM)
Notes from Interview with Debra (Medical Director of DCCC)
Software Requirements Specification Page 2
1.4 Assumptions and Dependencies
The following are the assumptions and dependencies of the EHR system at DCCC:
DCCC staff has little or more experience in using Allscipts. So training will be necessary.
Drexel College of Medicine has an enterprise license for AllScripts. When the new
version of AllScripts is released, it will be upgraded across the Drexel System of
Hospitals.
The AllScripts system will be integrated with IDX for no extra cost; hence it is assumed
that the existing billing and registration system which is part of IDX system will not be
changed.
Access control to the system is modulated by Drexel network which validates user login
credentials.
This system will require network access at the hospital to connect to the servers on
remote location.
Software Requirements Specification Page 3
2. SOFTWARE PRODUCT OVERVIEW
2.1 System Scope
The whole EHR system will be part of the Drexel College of Medicine (DUCOM)
network. The system will be hosted by DUCOM and Drexel servers. This includes web services
as well the databases to store the Health records. The authentication is also done by Drexel
network. The data stored and accessed by the EHR system will also be accessed by other system
across DUCOM. There will be seamless integration with IDX system which is a part of the
DUCOM network. The web services enables user to access the system from their terminals to the
servers. The terminals/laptop would require an Internet browser installed to be able to access the
system. It is the responsibility of the user to keep his/her credentials safe and not share it with
others. Apart from this, the system will auto log-out after 10 minutes of inactivity on the system
for security reasons.
2.2 System Architecture
This section defines the internal and external system architecture.
2.2.1 External View of Software Product
The following figure 1 shows the EHR system along the current and proposed systems.
This system can be accessed from terminals as well as laptops. Terminals are typically used by
office managers as well as system analysts. Also nurses at DCCC use their laptops to use the
EHR system. Drexel Specialists from DUCOM network of hospitals use their laptops to access
the patient‟s health records. The EHR system is hosted on the DUCOM servers and will be used
in the existing data servers to store the data. This might require some new servers in additional to
existing ones.
Other relevant systems which have access to Drexel data servers can use the data populated by
EHR system. For example, IDX can link patient appointments with the EHR of a patient created
by AllScripts.
Software Requirements Specification Page 4
Servers
Laptop
Nurse
Office Manager
Workstation
Add Patient Information,
Update existing information,
Provide educational material,
Search for patients,
Generate e-prescription
Generate referrals
Analyst Workstation
Run monthly/yearly reports
on number of patient’s visited,
Diagnosis and medication
Creating EHR,
Schedule appointments,
Set notifications
Users from Drexel Network of hospitals
Laptops
Web interface of
EHR system
Web interface of
EHR system
Web interface of
EHR system
EHR system
instance running
on the server to
handle user
requests
Data Storage
Data Flow
Figure 1: External View
Software Requirements Specification Page 5
2.2.2 Internal View of Software Product
The internal diagram of software product is shown in the figure 2. There are seven major
modules which are supported by the server application. Database module maintains patient
medical data. Integration with IDX module connects EHR system and IDX system (billing and
registration system). Other five modules process the major functions of the EHR system based
on the user‟s needs.
EHR System
Database-Store patient medical
records (basic patient
information, medical
notes, clinical findings,
attachments)
Prescription
Module
Integration
with IDX
Module
Documentation
Module
*
*
*
*
*
*
*
*
*
*
Notification
Module
User Access
Management
Module
Reporting and
System
Configuration
Module
*
*
*
*
Figure 2: Internal View
Software Requirements Specification Page 6
2. 3 Feature Overview
FEA1: Common Problem Palette (CPP) The nurses in DCCC usually treat the same medical conditions number of times. Some of these
common conditions are pre-built into the product so the nurses can just import the
documentation. The nurse can also save a template (CPP) that he/she has documented to reuse it.
FEA2: Document Management and Linking The users can access all the scanned documents and images related to a patient and also attach
new documents to a patient‟s record.
FEA3: Messaging and Tasks The users can send emails internally, so that eliminates the need to install an e-mail client. They
can create new mails and tasks through this feature.
FEA4: Ordering and capturing lab tests results The clinicians can order multiple tests, track incoming lab results and automatically attach the
results to patient records.
FEA5: E-prescription The nurse can prescribe medicines through AllScripts and send the prescription directly to the
pharmacist‟s computer.
FEA6: Health Maintenance The nurses and the physician will get a summary of tasks pending for a particular patient.
- Appointment notifications
- Labs/procedures that need be to be reviewed
- Medications that need refill
FEA7: Report generation The analysts who are given access to the data can generate monthly or yearly reports. The
analysts can extract and analyze medical data, track practice patterns, identify at-risk patient
populations and support disease management.
FEA8: Clinical Charting The nurses can maintain the progress notes and clinical findings based on the diagnosis and
patient data. The clinicians can use the Form Note Composer to perform this action.
FEA9: Patient Encounter The nurses have the tools to capture the pre-exam „work-up‟ and the physical exam/assessment
through AllScripts.
Pre-exam work-up: The nurses can record the patient vitals, medical history and multiple patient
complaints.
Physical exam/assessment: The nurses can access the clinical decision support systems and
manage problem and medication lists on the system.
FEA10: One page summary The clinicians can view the summary of all the data related to a single patient through this
Software Requirements Specification Page 7
feature.
FEA11: Medication Management
The nurses get alerted to medication allergies and receive drug interaction warnings. The EHR
pulls out information from the patient medical history and the standard drug database that is
available for all AllScripts software.
FEA12: Patient Education The clinicians can download preloaded educational materials for the patients which are updated
regularly.
FEA13: Referrals The nurse can refer the patient to a physician from DUCOM through AllScripts and eliminate all
the transcripts that were otherwise generated for referral. The office manager will then schedule
an appointment based on the schedules of the Physicians. The EHR will maintain a referral
history based on the patient, the provider and diagnosis.
FEA14: Data retrieval Nurses can search for a patient‟s record by typing the patient‟s name or Medical Record Number
(MRN)
Software Requirements Specification Page 8
3. SYSTEM USE
3.1 Support For User Workflows
DREXEL
SPECIALIST
OFFICE
MANAGERNURSE/PHYSICIAN
Walk-in Patient check-in
Create patient record
Generate appointment
Treat patient
Document treatment
Treat patient
Add visit note
Already automated
Not automated
Extent of automation
Pharmacy
Patient
DUCOM
PHARMACIST
Enter Insurance
Information
View
appointments
View patent
summary
Enter Medical
Notes
Enter Diagnosis
View/Attach
documents
Save Common
Problem Palette
(Template)
Order lab results
Download and give
patient educational
material
Schedule Referral
Appointment
Order
Prescription
Refills
Refill Prescriptions
Will be automated
Refer to Drexel
Specialist
Generate e-prescription
Figure 3: Swimlane diagram
Software Requirements Specification Page 9
3.2 Actor Survey
Role: Patient Most of the patients at DCCC fall into one of the following categories:
Working professionals at Centre City
Students (18-25 yrs) who do not have a primary care physician
People with no insurance
Visitors to Philadelphia
The patients are not direct users of AllScripts. The patients usually just walk-in and request for
an appointment to see a nurse. They come in for minor ailments such as cold, seasonal flu,
diabetes screening, skin problems, sinus, etc. The EHR stores all the data related to a patient
which is then used by the clinicians across DUCOM.
Role: Nurse The lead nurse and other part time nurses treat patients at DCCC. They are the primary users of
AllScripts. They are being trained in product usage. Most of the nurses are not experienced in
using an EHR. The nurses use AllScripts to view patient medical history, document diagnosis,
update patient record, order lab tests, attach lab test results and refer the patient to a Drexel
specialist.
Role: Physician The Physician at DCCC visits the clinic 2 hours a week and is available for consultation the
whole day. His usage of the system is limited to few hours a week, when he needs to go through
the patient summary and help in diagnosis.
Role: Office Manager The Office manager is expected to use AllScripts extensively. He uses the system in coalition
with the IDX billing and registration system. He needs to understand how the 2 systems work
together. Although he currently uses IDX for entering the billing and registration, he will be
using AllScripts to schedule an appointment within DCCC and also to schedule an appointment
with a Drexel specialist. He starts off the treatment process by adding a patient visit note and
assigning the patient to a nurse.
Role: Analyst The team of analysts work for DUCOM and do not directly work for DCCC. They use the
AllScripts and will be accessing the DCCC data for generating monthly or yearly reports to
analyze medical data, track high-risk patients, ways to improve patient care, and comparison of
health and insurance plans.
Software Requirements Specification Page 10
3.2 Use-Case Model and System Events
3.2.1 Use-Case Model
Figure 4: Use case diagram
Generate summary
Patient
Pharmacist
Drexel SpecialistManage referral appointment
Create EHROffice Manager
Generate ReportsAnalyst
Create/Maintain UsersAdmin
Search patient record
<<extend>>
Provide educational material
Manage Documents
Generate e-prescription
Create Template
Manage task/messages
Document Medical Record
<<include>>
Check Notification
<<extend>>
Nurse Practitioner
Login
Software Requirements Specification Page 11
3.2.2 System Events
BUSINESS EVENTS SYSTEM ACTION SYSTEM INTERACTION
Patient walks-in Search patient record using
name or MRN
Display patient record
Create patient record
Patient wants an
appointment
Scans nurse schedules and
finds slots
Books an appointment
Patient gives insurance
information
Saves the insurance
information
Interfaces insurance data with
insurance companies
Manager enters visit note Saves the visit note
Nurse wants to view her
appointment list
The appointment is populated
in the appointments section
Displays list of appointments for
the day
Nurse wants to view
patient summary
Scans and pulls up the
summary of patient‟s
information
Displays patient's one page
summary
Nurse wants to enter
patient diagnosis
Displays the diagnosis section
in the Form Note composer
Enters and saves diagnosis
Nurse wants to enter free
notes
Displays the free notes section
in the Form Note composer
Enters and saves free notes
Nurse wants to prescribe
medicines
Locates the nearest pharmacy Sends the prescription to the
pharmacy
Nurse wants to order lab
results
Sends lab test request to a lab
Nurse wants to view old
scanned documents
Pulls up all the documents
related to the patient
Displays the documents in the
attachments slider
Nurse wants to refill a
prescription
Scans and enters pharmacy
name, patient name and
medicines
Sends a refill request to the
pharmacy
Nurse wants to generate a
referral
Scans and displays the
available Drexel specialist
names
Enters and saves physician name,
patient name and referral reason
Manager wants to
schedule a referral
appointment
Scans the schedules of Drexel
Physicians
Generates a referral appointment
Nurse wants to give Downloads education material Displays relevant educational
Software Requirements Specification Page 12
education material to the
patient
from the database material
3. 3 System Interfaces
This section defines the main system interfaces to user features.
Login Screen
Home ScreenPatient Record
Templates
(CPP)
Notifications
Search Patient
Appointments
Generate
ReportE-prescription Documents
Messages
Refer Patient Lab ReportEducational
Material
New
Record
Update
Record
View
Document
Attach
Document
Search
Material
Material
Search
Availability
Add referral
Appointment
Send e-
prescription
Refill e-
prescription
Add
Template
(CPP)
Use
Template
(CPP)
Document
Report
View Lab
Report
Add Lab
Report
Print Lab
Report
Figure 5: UI diagram
Software Requirements Specification Page 13
4. SPECIFIC REQUIREMENTS
4.1 System Use-Cases
Use Case: Manage documents
Use-case name Manage documents
Actors Nurse
Brief Description This use case explains how the nurse practitioner can view
scanned documents and images in a patient‟s medical record
as well as attach new documents if required
Basic flow of events Actor action System action
1. INCLUDE Search
Patient Record
2. Nurse opens the
patient record and
navigates to the
documents section
3. The list of documents
available in the
patient‟s record is
displayed.
4. Nurse chooses the
relevant documents to
be viewed and clicks on
the documents
5. Document is displayed
to the Nurse
6. To add a new
document, Nurse clicks
on “add new document”
7. The upload page is
displayed
8. Nurse uploads new
document
9. Upload success
message is displayed
Alternative flow of events
Special requirements
Search patient record
Nurse
View Patient's Record
View Documents
Add Document
<<extend>>
<<include>>
<<include>>
Software Requirements Specification Page 14
Pre-conditions The Nurse has successfully logged into the system
Post-condition(s) The list of documents is updated with the new document
Extension points None
Use Case: Check Notification
Use-case name Check Notification
Actors Nurse/ Office Manager
Brief Description This use case explains how the nurse practitioner checks the
notifications in the Health record system
Basic flow of events Actor action System action
1. Nurse clicks
“Notifications” on the
Home page.
2. List of appointments,
incomplete health
records, pending tasks
is displayed
Alternative flow of events
Special requirements
Pre-conditions The Nurse has successfully logged into the system
Post-condition(s) Nurse clicks on the appropriate notification
Extension points None
Use Case: Manage Referral Appointment
Use-case name Manage Referral Appointment
Actors Office Manager
Brief Description This use case explains how the Office Manager processes
patient referrals to Drexel Specialists from the Drexel network
Check NotificationNurse
Log In
<<include>>
Office ManagerCheck Notification Search for Drexel Specailist
<<extend>>
Add appoitnment
<<include>>
Software Requirements Specification Page 15
of hospitals
Basic flow of events Actor action System Action
1. Nurse clicks
“Generate referral”
link
2. System displays list of
physicians from
Drexel
3. Nurse selects a
physician based on the
patient‟s diagnosis
4. Referral is created
5. Office manager adds
the referral to the
physician‟s
appointment list
Alternative flow of events
Special requirements
Pre-conditions The patient does not have a primary care physician
Nurse recommends a visit to Drexel Specialists for a patient
Post-condition(s) The referral was saved in the system
Appointment was generated
Extension points None
Use Case: Generate Report
Use-case name Generate Report
Actors Analyst
Brief Description This use case explains how the Analyst generates annual and
monthly reports from the EHR system.
Basic flow of events Actor Action System Action
1. Analyst clicks
“generate report”
2. Analyst selects criteria
3. Analyst select time
period and clicks
generate
4. Report is generated
Pre-conditions Analyst logs into the system
Post-condition(s) Reports are generated
Extension points None
Select Reports Generate reportAnlayst
Log In
<<extend>><<include>>
Software Requirements Specification Page 16
Use case: Create Template
Use case name Create Template
Actors Nurse
Brief Description This use case explains how the nurse can create a chart note
and save it for reuse or use an existing in-built template in
AllScripts
Basic Flow of events ACTOR ACTION SYSTEM ACTION
1. The user opens the Form Note Composer from the home page
2. INCLUDE Document Medical Record
3. The user goes to “New” and selects “Save as a New Common Problem Palette”
4. The Common Problem Palette is saved in the database
Alternative flow of
events
1a. The user clicks on
the “Multi problem
palette” icon in the
home page
The system displays the pre-built
“Common Problem Palette”
window
Document Medical Record
Import pre-built chartnote
Nurse
Create CPP
<<include>>
Save CPP
<<include>>
Software Requirements Specification Page 17
1b. The user selects one
of the pre-populated
medical condition
names and clicks Ok
The system imports the common
problem palette into the form note
composer
Special Requirements
Pre-conditions The user has successfully logged into the system
The patient record is created by entering the demographic
information
Post-conditions The template was successfully saved in the database
Extension Points Document Medical Record
Use Case: Search Patient Record
Use case name Search/ View Patient Record
Actors Nurse
Brief Description This use case explains how the nurse can search for a
patient‟s record and pull up a summarized view of the
View patient history
View scanned documents
View chart notes
Edit/customize summary
Enter patient name/MRN
Nurse Click Summary icon
<<include>>
<<include>>
<<include>>
<<include>>
Software Requirements Specification Page 18
patient‟s medical record. The nurse can also edit and
customize the patient summary based on what she wants to
see the next time she opens the summary
Basic Flow of events ACTOR ACTION SYSTEM ACTION
1. The user enters the patient’s name (first or last) or Medical Record Number in the search toolbar
2. Search results are displayed
3. The user clicks the “Summary” icon for a patient
4. The one page summary is displayed
5. In the summary page, the user clicks on the “Patient History” icon OR
The user clicks
the “Patient
Demographic” icon
6. Based on the selected option the patient information is displayed.
7. The user clicks on the attachments slider
8. All the scanned documents related to the patient is displayed
Alternative flow of
events
STEP BRANCHING ACTION
5a. The user goes to
“Options” and selects
“Viewing Options”
The “Options” window with
5b. The user can select
the checkboxes for the
options that she wants to
see in the summary. For
example, Vitals, Family
history, Allergy. She can
also change the order in
which she wants to view
these options
The summary page is customized
for the user.
Special Requirements
Software Requirements Specification Page 19
Pre-conditions The user has successfully logged into the system
The patient record has been created in the system
Post-conditions The search result was displayed based on the name or MRN
entered
The patient summary was successfully updated and saved in
the system
Extension Points None
Use case: Manage Messages
Use case name Manage Messages
Actors Nurse/Office Manager
Brief Description This use case explains how the nurse can create a new call or
task in AllScripts
USER ACTION SYSTEM ACTION
Basic Flow of events 1. The user clicks on the “New Message” drop down in the
Create New Call
Create New Task
View Inbox
Create New Message
Nurse
<<extend>>
<<extend>>
Software Requirements Specification Page 20
home page
2. The user selects the “New Task” option
3. The “New Task” window opens up
4. The user enters the Patient name, Phone number, Urgency, Due Date and Assigns To information in the fields on the screen
5. The user enters the task details and clicks Ok
6. A new task in created and the person to whom it is assigned receives the message
Alternative flow of
events
STEP BRANCHING ACTION
2a. The user selects the
“New Call” option in
the dropdown
The “New Call” window is
displayed
2b. The user assigns the
call to another user by
filling in the fields
Patient name, Phone
number, Assign To,
Urgency and Reason
A new call is created for the
person to whom it is assigned
1a. The user goes to the
Message center and
clicks on the inbox
All the messages in the user‟s
inbox are displayed
Special Requirements
Pre-conditions The user has successfully logged into the system
The user has the privileges to assign a task or call to another
user
Post-conditions The template task, call was successfully created and sent to
the users
Extension Points None
Software Requirements Specification Page 21
Use case: Generate e-prescription
Use-case name Generate e-prescription
Actors Nurse Practitioner
Brief Description A nurse practitioner can send a patient‟s prescription to the
pharmacist‟s computer directly.
Basic flow of events ACTOR ACTION SYSTEM ACTION
1. The nurse practitioner clicks
“New prescription” button
2. The system displays a form to
fill out e-prescription information.
3. The nurse practitioner enters
the e-prescription information
(medication name, patient
name, and a pharmacy location
for patient).
4. The system displays the list of
participating pharmacies
5. The nurse practitioner
selects one pharmacy from the
list based on the patient‟s will.
6. The system displays message
“The prescription was sent
successfully”.
Alternative flow of
events
Step Branching Action
1a. The nurse practitioner
clicks “Refill” button.
The system displays a previous
prescription summary including
medication and patient
information. The nurse practitioner
only enters pharmacy location to
search for convenient pharmacy.
4b. The systems displays a
warning for the medication
based on the patient‟s allergy
history.
The nurse practitioner changes the
medication.
Special requirements
Pre-conditions 1. The nurse practitioner is logged in to the system and at the E-
Prescription page.
2. The medical care for patient is finished.
3. The medication is not available at DCCC.
Enter e-prescription information
Nurse Practitioner
Select pharmacy Send e-prescription
<<include>>
Pharmacy
Software Requirements Specification Page 22
Post-condition(s) 1. The e-prescription was sent.
Extension points None
Use case: Provide educational material
Use-case name Provide educational material
Actors Nurse Practitioner
Brief Description A nurse practitioner can download educational materials from the
system for patients.
Basic flow of events Actor action System Action
1. The nurse practitioner clicks
“Educational Material” button.
2. The system displays a window
named “Educational Material”.
3. The nurse practitioner
selects one type of diseases
from a disease list.
4. The system displays a list of all
educational materials related to the
disease.
5. The practitioner right-clicks
one educational material and
selects “Print” (paper
educational materials).
Alternative flow of
events
Step Branching Action
5a. The practitioner right-
clicks one educational material
and selects “Save” (electronic
educational materials).
The electronic version can be
saved to patient‟s flash drive.
Special requirements None
Pre-conditions 1. The nurse practitioner is logged in to the system
2. The patient requests for some educational materials.
Post-condition(s) 1. The educational materials were printed out or saved to flash drive.
Extension points None
Select disease type
Select educational materialNurse Practitioner
Print/Save educational material
Software Requirements Specification Page 23
Use case: Create EHR
Use-case name Create HER
Actors Office Manager
Brief Description The office manager can create patient record including personal
information, insurance information and visit note and store it into the
system.
Basic flow of events Actor Action System Action
1. The office manager clicks
“New Patient” button.
2. The system displays a form to
fill out the new patient
information.
3. The office manager enters
patient information (patient
name, date of birth, weight,
height, SSN, insurance number
if the patient has, reason for this
visit), saves and submits it.
4. The system displays patient‟s
information and creates a medical
record number (MRN).
Alternative flow of
events
Step Branching Action
3a. Required data was not
entered.
System prompts the user to enter
the required but unfilled data.
Special requirements None
Pre-conditions 1. The office manager is logged in to the system
2. The patient doesn‟t have medical record in the system.
Post-condition(s) 1. The medical record of patient was stored to the system.
Enter patient information
Submit patient information
Generate medical record number
Office ManagerCreate EHR
<<include>>
<<include>>
<<include>>
Software Requirements Specification Page 24
2. The patient account was created.
Extension points None
Use Case: Document Medical Record
Update Patient Information
Add CC (Chief Complaint) Note
Add HPI (History of Present
Illness) Note
Add Hx(History) Note
Check Notification
Generate CC Note
Generate HPI Note
Generate Hx Note
Nurse PractitionerDocument Medical Records
<<extend>>
<<extend>>
<<include>>
<<include>>
<<include>>
<<extend>>
<<extend>>
<<extend>>
Software Requirements Specification Page 25
Use-case name Document Medical Record
System or subsystem System
Actors Nurse Practitioner
Brief Description The nurse practitioner adds/updates patient information, progress
notes and clinical findings.
Basic flow of events Actor Action System Action
1. The nurse practitioner
clicks a small icon named
“create a new note” under the
patient name at the main
screen.
2. The system displays a form
named “Patient”. There are
different tabs (Patient, CC, HPI,
Hx) on the top of the window. User
can switch those tabs to add/update
different data.
3. The nurse practitioner
enters patient information
(including height, weight,
temperature, blood pressure)
in the “Patient” page, and then
clicks “Update” button.
4. The system displays patient
information chart.
5. The nurse practitioner
clicks tab “CC” (Chief
Complaint).
6. The system displays a form to fill
out patient symptom.
7. The nurse practitioner
selects one certain category of
symptom.
8. The system displays a list of all
the content (specific symptom)
related to the symptom.
9. The nurse practitioner
selects one specific symptom
and enters free text to add
some specific things, and then
submits it.
10. The system generates the
symptom note.
11. The nurse practitioner
clicks “HPI” (History of The
Present Illness).
12. The system displays a category
including general questions
(Location, Severity, Frequency and
Timing, Onset) related to the
symptom.
13. The nurse practitioner
selects one category
(question).
14. The system displays other
categories to show the specific
questions.
15. The nurse practitioner
selects answer for each
specific question.
16. The system generates the HPI
note automatically.
17. The nurse practitioner
clicks “Hx” (History).
18. The system displays a history
category (medical history, surgical
history, social history, allergy
history).
19. The nurse practitioner
selects one history.
20. The system displays other
categories to show the specific
questions.
Software Requirements Specification Page 26
21. The nurse practitioner
selects answers for further
specific questions about the
history.
22. The system generates the
history note automatically.
Alternative flow of
events
Step Branching Action
3a. The patient information
already exists in the system
and doesn‟t need any update;
so the nurse practitioner skips
this form and updates other
notes.
The system displays
Special requirements None
Pre-conditions 1. The nurse practitioner is logged in to the system and at the main
screen.
2. The patient has medical records in the system.
Post-condition(s) 1. The patient information/chief complaint/history of the present
illness/history information was updated.
2. The progress notes were updated.
Extension points Check Notification
4.2 System Functional Specification
Server Application Module - The following high-level functions will be supported by the
services on the server.
AllScripts Database Module - This module comprises of functions that deal with maintaining
the data in the AllScripts database.
Add Data
Delete Data
Update Data
Search Data
Backup Data
User Access Management - This module includes functions related to user management of the
system.
Add new user
Change privileges Delete User
Documentation Module - This module supports the functions from the User interface
module. These functions are triggered by the user interface functions and are executed on the
server.
User log-in and authorization
Software Requirements Specification Page 27
Main menu
Create New User
Search patient
Show patient Record
Update Patient Record
Add Document
Prescription Module - This module includes functions which are part of the e-prescription
functionality provided by EHR system.
Create new e-prescription
Send e-prescription
Refill e-prescription
Notifications Module The functions in this module include the processing of the notifications generated by other
modules
Show Notification
Reporting and System Configuration Module This module has the functions to generate reports and configure the system.
Generate Report
Update Software Version
IDX-AllScripts Integration Module - This section comprises of the integration functions which integrate IDX and AllScripts.
Get Diagnosis Code (Get the Diagnosis code from AllScripts)
Get Medication Code (Get the Medication code from AllScripts)
Search Appointments (Displays availability of Drexel Specialists)
User Interface Module
The transactions on the EHR system will be executed on the server hardware. The user interface
module will request services from EHR system on the server. This module is responsible
for the user interface and the screens displayed. It also generates HTTP requests based on
the clicks to enable services by the EHR.
Display User login and authorization
Display Main menu screen
Display New User creation
Display Search for patient
Display patient Record
Software Requirements Specification Page 28
Display Send e-Prescription
4.3 System Domain Models
4.3.1 Internal Domain Model
Figure 6: Class diagram
4.3.2 Data Models
The high level object-oriented class diagram is shown following. Basic patient information will
be stored in the Allscripts database. User can retrieve patient information from Allscripts
database. Patient insurance and history information are both important. Treatment fee can be
covered if patient has insurance. Patient history information helps nurse understand patient
thoroughly. Patient makes appointment and office manager schedules that.
Nurse will examine patient and then create prescription and invoice. If the patient has serious
Software Requirements Specification Page 29
condition, nurse will refer him/her to Drexel hospital. When the medications on prescription are
available at Drexel Convenient Care Center (DCCC), patient will get them immediately. Since
nurses can retrieve medication information from inventory to monitor its availability, they make
sure that each kind of medication is available in order to provide quick and quality medical care.
If medications are not available, nurse will send an e-prescription to a pharmacy which is
convenient to pick up them for patient.
DCCC staff is using IDX as the billing and registration system so the integration with IDX is
necessary. The treatment fee is determined by diagnosis code in EHR system and then invoice is
generated in IDX system.
4.4 Non-Functional Requirements
4.4.1 Usability
NFR1: The system should support the practice to
improves patient care
speeds up the treatment process
NFR2: The system should automatic paper work to reduce duplication of effort and increase
employee efficiency
NFR3:The UI screens should be customized based on the usage of the EHR in a small clinic like
DCCC
NFR4: Standard UI elements and consistent workflow should be consistent
NFR5: The users expect the development team to minimize the number of screens in the
AllScripts by creating additional built in templates that can be used in DCCC
NFR6: The system should be intuitive enough for a new user to learn within 10 days of formal
training
NFR7: It should take 3-4 days for a power user to get trained in usage of the EHR
NFR8: The task of documenting medical notes in the EHR should not 15 minutes
4.4.2 Reliability
NFR 9: The system should be available 99.9% of time for 5-6 users. The system will be used 12
hours a day.
NFR10: The system saves sensitive medical data for thousands of patients. Hence the design
must consider the integrity and security of the data
NFR11: The data will be backed up everyday
NFR12: The system should display 100% accurate data
Software Requirements Specification Page 30
4.4.3 Performance
NFR13: The AllScripts system should be responsive and improve decision making
NFR14: The system should be scalable from 4 to 100 users
NFR15: The system should be able to find a patient‟s record in less than 10 seconds
NFR16: The system should be able to locate a pharmacy in less than 7 seconds
4.4.4 Supportability
NFR17: It is foreseeable that the product will be upgraded to the next version in a span of 3-4
months. The development team will have a process for upgrading the software to the next
version.
NFR18: Users might want to save templates of the medical conditions that most frequently
document. This should be allowed without any loss of integrity.
NFR19: The system should be interoperable with the IDX billing and registration system.
5. SUPPLEMENTARY REQUIREMENTS
5.1 Project management strategy
The design and development team will use this document as their reference document. Any
issues with the requirements presented here can be discussed in the team meetings. Future
changes in interfaces or APIs with other system will be periodically checked.
5.2 Systems Security and Audit
The proposed customized version of AllScripts will retain the security standards followed by
AllScripts Professional EHR system. It will meet or exceed HIPAA standards which govern
the privacy of patient information. The following features are part of the EHR system
security and audit functionalities:
Access Control:
o Unique user IDs - There will be no duplicate users, thus be able to track
responsible individuals.
o Emergency access - In the event of emergency situation, limited access is
provided for special log-in‟s
o Automatic log-off - After a period (10 minutes) of brief inactivity on the system,
the user will be logged-off and redirected to log-in screen to resume the usage.
Audit Controls: Record of all accesses and updates are maintained in a separate and
secure location
Transmission Security: Encrypted transfer of data will be supported
Software Requirements Specification Page 31
Integrity: Data is stored in a Microsoft SQL database to ensure integrity and recover
ability
Person or Entity Authentication: Additional user authentication is for access to reports
and documents.
5.3 Assumptions and Dependencies
For information on assumptions and dependencies, please refer to sections 4.4.2, 4.4.2 and 4.4.3.
5.4 Requirements Traceability
The following table maps use-cases onto the functional and non-functional requirements listed in
section 4:
Key: Fn is High-Level System Feature n (from section 2.2.1).
Sn is Non-Functional or Supplementary requirement n (from section 3.2).
High-Level Features Mapped onto Use-Cases
FEATURES UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8 UC9 UC10 UC11
FEA1: Common Problem Palette X
FEA2: Document Management and Linking X
FEA3: Messaging and Tasks X
FEA4: Ordering and capturing lab tests results X X
FEA5: E-prescription X
FEA6: Health Maintenance X
FEA7: Report Generation X
FEA8: Clinical Charting X X
FEA9: Patient Encounter
FEA10: One page Summary X
FEA11: Medication Management X X
FEA12: Patient Education X
FEA13: Referrals X
FEA14: Data Retrieval X
Software Requirements Specification Page 32
Use-Cases Mapped Onto Non-Functional and Supplementary Requirements
Use-
Case NF1 NF2 NF3 NF4 NF5 NF6 NF7 NF8 NF9 NF10 NF11 NF12 NF13 NF14 NF15 NF16 NF17 NF18 NF19
UC1 X X X X X X X
UC2 X X X X X X X
UC3 X X X X X
UC4 X X X X X X X
UC5 X X X X X
UC6 X X
UC7 X X X X X X
UC8 X X X X X X X
UC9 X X
UC10 X X X X X
UC11 X X X
Software Requirements Specification Page 33
6. ONLINE USER DOCUMENTATION AND HELP SYSTEM REQUIREMENTS
6.1 Training
All the DCCC staff will be provided complete training by the Drexel College of Medicine.
There will be 2-day training session which is customized for the office manager, the other
administrative staff and for the nurses in DCCC. Training will include sample scenarios. The
training manual will be given to the users which include screenshots of the system to assist them
immediately. DUCOM has developed their own training material that is used for training
clinicians in AllScripts.
6.2 User Documentation
There will be an exhaustive user manual which will explain all the functionalities of the system.
This will be available both as a soft copy and hard copy. The manual will also contain
screenshots for all the features.
6.3 User Support DCCC will have a dedicated person for first week to support on the location to assist with using
the system. There will be direct line for support on the phone for the 1st month after the
installation of the EHR system. After that support will be provided by general customer service.
7. DESIGN CONSTRAINTS
The user - side web interface of the system must send request in https, thus being secured which
is highly desired by from this system. These requests will then be translated into SQL queries for
Microsoft SQL server database.
The EHR system will be support all the requirements specified by HIPAA.
8. INTERFACES
8.1 User Interfaces
Check boxes
Menus
Number of keystrokes reduced with suggestions
Pop-ups for alerts and notifications
Online help
Number of clicks reduced by generating most features
Number of screens
The system must be secure, with only the DCCC staff having login access
Software Requirements Specification Page 34
8.2 Hardware Interfaces
Refer to section 2.2.1 to read about external interfaces.
8.3 Software Interfaces
Reference to section 2.2.1 and 2.2.2
8.4 Communications Interfaces
Reference to section 2.2.1
9. LICENSING REQUIREMENTS
Drexel College of Medicine has an enterprise license for AllScripts. When the new version of
AllScripts is released, it will be upgraded across the Drexel System of Hospitals.
10. APPLICABLE STANDARDS
GLOSSARY
Diagnosis code: Diagnosis codes are numbers given to a service provided to a patient including
medical, surgical and diagnostic services. These codes are used to generate bill for the procedure
and are referred by insurance companies to determine the reimbursement amount.
IDX: IDX is a former health care software company which was acquired by General Electric.
Now it is called the GE Healthcare‟s IDX software for billing and registration.
http://www.gehealthcare.com/company/pressroom/releases/pr_release_10324.html
Software Requirements Specification Page 35
APPENDIX
Feature 1: Home Page
Feature 2: Customization Page
Software Requirements Specification Page 36
Software Requirements Specification Page 37
Feature 3: Documenting Medical Records (including basic patient information, chief complaint, history of present illness, etc)
Software Requirements Specification Page 38
Feature 4: Generating Progress Notes (Symptom will be generated automatically on notes, and also nurse can type free text)
Feature 5: Referral (Nurse will view the referral information)