Software Requirements Specification - Personal Websites - Office

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)

http://www.google.com/url?q=http%3A%2F%2Fwww.allscripts.com%2F&sa=D&sntz=1&usg=AFQjCNHcKU_5TgL8n2q3JZ8pveToRH_EEw


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.


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.


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


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


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


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)


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


Figure 3: Swimlane diagram


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.


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


Create Template

Manage task/messages

Document Medical Record

<<include>>

Check Notification

<<extend>>

Nurse Practitioner

Login


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


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

Print

Material

Search

Availability

Add referral

Appointment

Send e-

prescription

Refill e-

prescription

Add

Template

(CPP)

Use

Template

(CPP)

Print

Document

Print

Report

View Lab

Report

Add Lab

Report

Print Lab

Report

Figure 5: UI diagram


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>>


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



Pre-conditions The Nurse has successfully logged into the system

Post-condition(s) Nurse clicks on the appropriate notification


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>>


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



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


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


Select Reports Generate reportAnlayst

Log In

<<extend>><<include>>


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>>


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>>


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.




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>>


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



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


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.


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


Post-condition(s) 1. The e-prescription was sent.


Use case: Provide educational material

Use-case name Provide educational material


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”.


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


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.


Select disease type

Select educational materialNurse Practitioner

Print/Save educational material


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.


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


3a. Required data was not

entered.

System prompts the user to enter

the required but unfilled data.


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>>


2. The patient account was created.


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>>


Use-case name Document Medical Record

System or subsystem System


Brief Description The nurse practitioner adds/updates patient information, progress

notes and clinical findings.



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.


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.


clicks tab “CC” (Chief

Complaint).

6. The system displays a form to fill

out patient symptom.


selects one certain category of

symptom.

8. The system displays a list of all

the content (specific symptom)

related to the symptom.


selects one specific symptom

and enters free text to add

some specific things, and then

submits it.

10. The system generates the

symptom note.


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.


selects one category

(question).

14. The system displays other

categories to show the specific

questions.


selects answer for each

specific question.

16. The system generates the HPI

note automatically.


clicks “Hx” (History).

18. The system displays a history

category (medical history, surgical

history, social history, allergy

history).


selects one history.

20. The system displays other

categories to show the specific

questions.



selects answers for further

specific questions about the

history.

22. The system generates the

history note automatically.

Alternative flow of

events


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


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


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


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


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


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


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


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


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


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

http://www.gehealthcare.com/company/pressroom/releases/pr_release_10324.html


APPENDIX

Feature 1: Home Page

Feature 2: Customization Page


Feature 3: Documenting Medical Records (including basic patient information, chief complaint, history of present illness, etc)


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)

Software Requirements Specification - Personal Websites - Office

Documents

Transcript of Software Requirements Specification - Personal Websites - Office