Download Software Requirements Specification for a Medical Information System and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!
Florida Gulf Coast University Digital Hospital and Medical Information System
Computer Information Systems Program
College of Business
Florida Gulf Coast University
Team Eagle: Joe Ciliberti capstone@fxkustomimports.com
Eugene Hoyt eugenehoyt@aol.com
Bill Mack wbmack1@msn.com
Jamie Lewis jflewis@eagle.fgcu.edu
Project Mentor Janusz Zalewski, Ph.D. Zalewski@fgcu.edu
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope of Document
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview of document
2. Description of Project
2.1 Project Overview
2.2 Project Functions
2.3 User Characteristics
2.4 Constraints to Project Development and Implementation
2.5 Assumptions and Dependencies
3. Specific Requirements of Physician Office System
3.1 Functional Requirements of Physician Digital Record System
3.2 Non- Functional Requirements of Physician Digital
Record System
3.3 Physician Digital Record System Performance
3.4 Logical Database Requirements
3.5 Design Constraints
4. Specific Requirements of Hospital System
4.1 Functional Requirements of Hospital Digital Record System
The software requirement specification document is specifically designed to delineate the boundaries of the Healthcare Information System design and functionality. Parties interested in this documentation would include but not be limited to the system owners, the system users, the project manager and the design team.
1.2 Scope of Document
This document will identify the pertinent software products we will develop including a Host DBMS, JAVA software supported and web-based Patient, Physician, and Ambulatory Input/Outputs, and sensor driven inputs for real-time patient monitoring. The SRS will show that we will be utilizing SQL server and ASP for interfacing with the Input/Outputs as well as Java applets for the real-time acquisition of health data from remote sources. Finally, utilizing the security attributes of XML, XSL, and a secure socket layer in the protocol stack we hope to address the valid security concerns about the networking and transmission of confidential health care information. In addition to the specific design components of this software, this document will make clear the design team’s goals of creating value-added software which not only correctly captures patient health information, but then efficiently stores it, sorts it, retrieves it, and delivers this critical care information where it is needed by healthcare professionals. The benefit of having accurate, complete, and timely health information is that it will inevitably save human lives. This software is deliberately focused on medical records and the associated diagnostics. It is important to point out that this system which is life critical will not have cross functionality regarding appointment management, billing, or insurance functions, however diagnostic codes sets will be compliant with present Federal law.
1.3 Definitions, Acronyms, and Abbreviations
1.3.1 Electro-cardiogram (EKG). A device that measures the electrical activity in a biological heart and measures heart rate.
1.3.2 Pulse oximeter. A device that employs monochromatic light to measures percentages of oxygenated hemoglobin in blood.
1.3.3 Systolic blood pressure. The peak pressure in the arterial circulatory system.
1.3.4 Diastolic blood pressure. The pressure at which the heart’s aortic valve closes.
1.3.5 Emergency medical technician (EMT). A trained emergency healthcare specialist.
1.3.6 Oscilloscope monitor. A cathode ray tube capable of representing a beam of light that simulates a heart rhythm waveform.
1.3.7 (HIPAA) -The Health Insurance Portability and Accountability Act of 1996
1.3.8 (SDLC)-The Systems Development Life Cycle.
1.3.9 Non-Digitized Professionals. Health Care providers who have no access to digital records through lack of hardware, software, or preference to legacy flat file charting methods.
1.3.10 (AES)-Advanced Encryption Standard
1.3.11 (DSP) -Distributed Services Provider
1.3.12 (ASP) –Application Service Provider
1.3.13 (FAT32) - File Allocation Table 32 Bit
1.3.14 (TIFF) – Tag Image File Format
1.3.15 (JPEG) - Joint Photographic Experts Group
1.3.16 (DOB) – Date of Birth
1.3.17 Vendor. A licensed and authorized agent of the development team or their vested remaindermen.
1.3.18 ISO 8601. A standard format for representing date and time recommended by the International Organization for Standardization
1.3.19 Initial patient information. Information normally gathered during a patient’s first arrival in a healthcare provider’s office or in an emergency room. This includes but not limited to name, address, Social Security Number and any health insurance numbers.
An information system which is primarily linked between a physician’s office and his hospital would be able to capture and store data from either location giving access to diagnostics from satellite locations. Added functionality could include ability to gather data in real time from a remote monitor or an inbound Emergency transport vehicle. [2] This information system is an industry-compliant application, based upon an open architecture (Microsoft NT/SQL relational database), and is designed to function within a standard IEEE compliant Ethernet (10 or 100) Local or Wide Area Network environment, and will also include Wireless capabilities. The communications protocol is TCP/IP, and is supported under any routing protocol within an infrastructure (routed or bridged). The software is based upon standard and emerging web technologies, requiring a workstation to only be capable of running an Internet Browser such as Microsoft’s Internet Explorer and Netscape Navigator. Within the browser Java applets will parse and display real-time data in the form of streaming MPEG 4 video, still images in JPEG or Tiff format, and a java bean real-time graph plotter from diagnostic equipment anywhere within the network. As a Distributed Systems Provider (DSP) the system offers all the advantages of an Application Service Provider (ASP), but overcomes security and proximity issues by allowing hospitals to keep the primary system at their facility.
2.2 Project Functions
2.2.1 The software code should be portable between different operating systems such as Linux and Windows. 2.2.2 The software should be easy to use and should require minimum manual operation. 2.2.3 The software should have a user-familiar interface so that the system would not pose an additional workload to the users. Note. Interface design would follow generally accepted model conventions for placement of dropdown menus and toolbars.
2.2.4 The software should allow bidirectional synchronous communication between the user and the data source in real time. 2.2.5 The software should provide security of operation and confidentiality of information (restricting access to non-privileged users), by FAT compression of data and Rijndael (AES) encryption algorithms. 2.2.6 The software should allow collection of vital signs and still images of the patient for visual inspection by experts. 2.2.7 The software should have tools for computer assisted diagnosis like an electronic stethoscope, a blood oxygen sensor, EKG, and a digital sphygmomanometer. 2.2.8 The software should be able to avoid congestion while transmitting high volumes of data and images in real-time. 2.2.9 The software should sample video images from diagnostic equipment automatically at 30fps or rates compatible with the transmission capacity available. 2.2.10 The software should be able to interface and link all components of system refer to Figure 2.2.
Figure 2.2.1 Context Diagram
2.2.11 The system will extend the data capabilities of the Physician’s office, the hospital, and emergency personnel. Refer to Figure 2.2.
Figure 2.2.2 Use Cases
2.3 User Characteristics
2.3.1 The primary user will be a healthcare professional like a physician, a nurse, or an emergency medical technician.
2.5.2 The SDLC chosen to implement the system will be model driven and based on subsequent versions to insure data integrity and functionality. Refer to figure 2.5. 2.5.3 Due to report length constraints imposed by CISDC, HIPAA regulations will be strictly followed but kept as a stand alone document.
Model Driven System Development Life Cycle
Figure 2.5.1 Model Driven Hybrid SDLC
3. Specific Requirements of Physician Office System
3.1 Functional Requirements of Physician Digital Record System
3.1.1 The software must allow input of patient data from patient (initial) home, secured access at Physician and Nurse Workstations, and from the data streaming real-time monitoring equipment. Note. A web-based system can allow initial patient information to be gathered by a dumb terminal in office or from patient’s own computer upon Email appointment verification hyperlinked to a web-based input screen. 3.1.2 The software must request username and password for access to data, only after authentication will allow access to the system. 3.1.3 The software must require high levels of error correction and input validation.
Note. Message box prompts would require a second entry of key data fields including name, DOB, Social Security Number, medications and allergies. Doctor’s inputs will similarly prompt proper code sets for diagnosis.
3.1.4 The software must allow browsing by the physician of historical medical
information of his/her patients only.
3.1.5 The software must identify the patient by a unique numeric identifier
derived from a function performed on the patient’s birth date. Note. Algorithm will be simply TODAY-BIRTHDAY = NUM& Doctor key & Increment (Increment will be added if duplicate number found in Database.)
3.1.6 The software must retrieve, update, and store data from multiple input
locations including but not limited to hospital workstations, physician workstations, inbound emergency vehicles, and electronic monitoring equipment.
3.1.7 The software must allow patient to view their own medical record online
allowing changes only to address, phone number, and insurer after initial input.
3.1.8 The software must only allow deletions by the vendor and only after
archiving data in flat file format. Reference 2.4. Note. Deletions will only be performed at the request of the patient or the decedent’s heirs in compliance with HIPAA guidelines.
3.1.9 The software to be developed must display the correct patient name.
3.2.3 More than three attempts at login and failure will produce a red flag to system administrator.
3.3 Physician Digital Record System Performance Requirements
3.3.1 The Physician software should be able to support at least three simultaneous users. 3.3.2The Physician software should support diagnostics inputs (see section 5.1), three terminals and a SQL server database. 3.3.3 95% of the transactions shall be processed in less than one second. 3.3.4 Data should be secured and backed up every quarter hour. 3.3.5 Power supply should have a back up and a disaster recovery plan. 3.3.6 System should be operable 24 hours a day and accessible in real-time. 3.3.7 Secure Socket Layer 3.0 with 128 bit encryption will enable network security
3.4 Logical Database Requirements
Figure 3.4.1 Physicians Office Entity Relationship Diagram
3.5 Design Constraints
3.5.1 Hardware, software, and data communication elements must be sourced within budgetary constraints.
4. Specific Requirements of Hospital System
4.1 Functional Requirements of Hospital Digital Record System
4.1.1 The software must allow input of patient data from the patient and the Physician.
Note. A web-based system can allow initial patient information to be gathered by a dumb terminal in office or from patient’s own computer upon Email appointment verification hyperlinked to input screen.
4.1.2 The software must request username and password for access to data,
only after authentication the system will allow access.
4.1.3 The software must require high levels of error correction and input
validation. Note. Message box prompts would require a second entry of key data fields including name, DOB, Social Security Number, medications and allergies. Doctor’s inputs will similarly prompt proper code sets for diagnosis.
4.1.4 The software must allow browsing by the physician of historical medical
information of his/her patients only.
4.1.5 The software must identify the patient by a unique numeric identifier
derived from a function performed on the patient’s birth date. Note. Algorithm will be simply TODAY-BIRTHDAY = NUM & Doctor Key & Increment (Increment will be added if duplicate number found in Database.)
4.1.6 The software must retrieve, update, and store data from multiple input
locations including but not limited to hospital workstations, physician workstations, inbound emergency vehicles, and the electronic monitoring equipment.
4.1.7 The software must allow patient to view their own medical record online
allowing changes only to address, Insurance # and phone number.
4.2.1 The software interface must follow design conventions which allow for familiar location of drop down menus, help etc. 4.2.2 Input errors will be returned in red with appropriate message box. 4.2.3 More than three attempts at login and failure will produce a red flag to system administrator.
4.3 Hospital Digital Record System Performance Requirements
3.3.1 The Hospital software should be able to support up to 300 simultaneous users. 3.3.2The Hospital software should support an internet server, diagnostics inputs (see section 5.1), thirty two terminals and a SQL server database. 3.3.3 95% of the transactions shall be processed in less than one second. 3.3.4 Data should be secured and backed up every quarter hour. 3.3.5 Power supply should have a back up and a disaster recovery plan. 3.3.6 System should be operable 24 hours a day and accessible in real-time. 3.3.7 Secure Socket Layer 3.0 with 128 bit encryption will enable network security
4.4 Logical Database Requirements
TBD
4.5 Design Constraints
4.5.1 Hardware, software, and data communication elements must be sourced within budgetary constraints.
5. Specific Requirements of Real-time Patient Monitoring System
5.1 Functional Requirements of Real-time Patient
Monitoring System
5.1.1 The software to be developed shall accept output from existing patient monitoring equipment. 5.1.2 The software to be developed shall display graphical and numeric data at a remote location in real time. 5.1.3 The software to be developed shall graphically display output from an EKG oscilloscope monitor.
5.1.4 The software to be developed shall display numeric output from an EKG monitor. 5.1.5 The software to be developed shall display numeric percentages from a pulse oximeter. 5.1.6 The software to be developed shall display numeric values for systolic blood pressure. 5.1.7 The software to be developed shall display numeric values for diastolic blood pressure. 5.1.8 The software to be developed shall display numeric values for mean blood pressure. 5.1.9 The software to be developed shall display numeric values for body temperature. 5.1.10 The software to be developed shall display text values for patient identification. 5.1.11 The software to be developed shall display text values for time of day.
5.2 Non- Functional Requirements of Real-time
Patient Monitoring System
5.2.1 The software to be developed must display correct numeric pulse oximeter values at a remote location within five seconds. (Note. Correct values within 3% of actual [1]) 5.2.2 The software to be developed must display correct numeric EKG values at a remote location within five seconds. 5.2.3 The software to be developed must display a correct graphical EKG oscilloscope waveform at a remote location within five seconds. 5.2.4 The software to be developed must display correct numeric blood pressure values at a remote location within five seconds. 5.2.5 The software to be developed must display correct numeric body temperature values at a remote location within five seconds. 5.2.6 The software to be developed must display the correct patient name. 5.2.7 The software to be developed shall display the correct time of day. 5.2.8 The software to be developed must operate twenty-four hours a day.
6.3.6 The software to be developed shall display numeric values for systolic blood pressure. 6.3.7 The software to be developed shall display numeric values for diastolic blood pressure. 6.3.8 The software to be developed shall display numeric values for mean blood pressure. 6.3.9 The software to be developed shall display text values for patient identification.
6.2 Non- Functional Requirements of Ambulatory Medical System
6.4.1 The software to be developed must display correct numeric pulse oximeter values at a remote location within five seconds. (Note. Correct values within 3% of actual [1]) 6.4.2 The software to be developed must display correct numeric EKG values at a remote location within five seconds. 6.4.3 The software to be developed must display a correct graphical EKG oscilloscope waveform at a remote location within five seconds. 6.4.4 The software to be developed must display correct numeric blood pressure values at a remote location within five seconds. 6.4.5 The software to be developed must operate twenty-four hours a day.
6.3 Real-time Ambulatory Medical System
Performance Requirements
TBD
6.4 Design Constraints
TBD
End of Software Requirements Specification
