• No results found

Software Requirements Specification. Company Name: Team 5

N/A
N/A
Protected

Academic year: 2021

Share "Software Requirements Specification. Company Name: Team 5"

Copied!
41
0
0

Loading.... (view fulltext now)

Full text

(1)

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

(2)

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

(3)

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

(4)

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)

(5)

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.

(6)

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.

(7)

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

(8)

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

(9)

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

(10)

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)

(11)

3. SYSTEM USE

3.1 Support For User Workflows

DREXEL SPECIALIST OFFICE

MANAGER

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

(12)

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.

(13)

3.2 Use-Case Model and System Events 3.2.1 Use-Case Model

Figure 4: Use case diagram

Generate summary

Patient Pharmacist

Drexel Specialist Manage referral appointment

Create EHR Office Manager Generate Reports Analyst Create/Maintain Users Admin

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

(14)

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

(15)

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 Screen Patient Record Templates (CPP) Notifications Search Patient Appointments Generate Report E-prescription Documents Messages

Refer Patient Educational Lab Report

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

(16)

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

(17)

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 Notification

Nurse Log In

<<include>>

Office Manager

Check Notification Search for Drexel Specailist <<extend>>

Add appoitnment <<include>>

(18)

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 report

Anlayst Log In

(19)

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

(20)

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

(21)

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.

(22)

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

(23)

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

(24)

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

(25)

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 material Nurse Practitioner

(26)

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 Manager

Create EHR

<<include>>

<<include>>

(27)

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 Practitioner

Document Medical Records <<extend>> <<extend>> <<include>> <<include>> <<include>> <<extend>> <<extend>> <<extend>>

(28)

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.

(29)

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.

(30)

 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

(31)

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

(32)

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

(33)

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

(34)

 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

(35)

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

(36)

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

(37)

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.

(38)

APPENDIX

Feature 1: Home Page

(39)
(40)

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

(41)

Feature 4: Generating Progress Notes (Symptom will be generated automatically on notes, and also nurse can type free text)

References

Related documents

Assessment of Microstructure and Mechanical Behavior of Assessment of Microstructure and Mechanical Behavior of Materials and Phases Observed in Low-Enriched Uranium Materials

Enter Template Name: Enter an appropriate template name (e.g. Funds to Farm Credit; Vendor Payments; Payroll; etc.). Enter Company Description: Enter an appropriate

In conclusion, HL survivors who have been treated with abdominal radiotherapy and/or procarbazine have a high prevalence of advanced colorectal neoplasia and serrated

Use the drop-down list next to student’s name to view and enter the specified student’s grades for all course activities, or view and enter the comments and details.. To view

The purpose of this tech note is to give guidance for configuring an OSPC phonebook data source to make use of Microsoft’s Active Directory using LDAP..

Moved by Director Cardenas, seconded by Director Hanks, that the board approve the following minutes of the Imperial Irrigation District Board of Directors with three minor

Normally, the prospects of rising yields and steepening yield curves send shivers down the spine of most fixed income managers. This is because rising yields cause the price of

• To view the Dynamic Report Summary of a specific report, enter the corresponding Report Name, Creator’s Name or Keyword in the Search Dynamic Reports dialog box and then click