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