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
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.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
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)
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
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 * * * *
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
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
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
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 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
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
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
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
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>>
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
Use case: Create Template
Use case name
Create TemplateActors
NurseBrief 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 AllScriptsBasic Flow of events
ACTOR ACTION SYSTEM ACTION 1. The user opensthe 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 RecordActors
NurseBrief Description
This use case explains how the nurse can search for a patient‟s record and pull up a summarized view of theView 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 entersthe 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.
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 MessagesActors
Nurse/Office ManagerBrief Description
This use case explains how the nurse can create a new call or task in AllScriptsUSER ACTION SYSTEM ACTION
Basic Flow of events
1. The user clicks onthe “New Message” drop down in the
Create New Call
Create New Task View Inbox
Create New Message Nurse
<<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
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
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>>
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
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>>
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>>
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.
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.
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.
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
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
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
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
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.
APPENDIX
Feature 1: Home 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)