Digital Hospital and
Medical Information System
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
4.2 Non- Functional Requirements of
Hospital Digital Record System
4.3 Hospital Digital Record System
Performance
4.4 Logical Database Requirements
4.5 Design Constraints
5. Specific Requirements of Real-time Patient
Monitoring System
5.1 Functional Requirements of Real-time
Patient Monitoring System
5.2 Non- Functional Requirements of
Real-time Patient Monitoring System
5.3 Real-time Patient Monitoring System
Performance
5.4 Design Constraints
6. Specific Requirements of Ambulatory Medical System
6.1 Functional Requirements of
Ambulatory Medical System
6.2 Non- Functional Requirements of
Ambulatory Medical System
6.3 Real-time Ambulatory Medical System
Performance
6.4 Design Constraints
1. Introduction
1.1 Purpose
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 (ECG). 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.
1.3.20 (fps) – Frames per second
1.3.21 (CISDC) – Computer Information
Society Design Competition
1.4 References
[1] Mack, Francis E. MD, Personal Interview February 1, 2003
[2]Sundaram, Senthilnathan, Requirements Analysis of Software
Requirements for Telemedicine and the HealthCare Industry, Master Thesis,
UCF,
Orlando,
Florida, July 19, 2002
1.5 Overview of document
The Software
Requirement Specification will define and illustrate the overall project and
its requirements- both functional and non-functional. In addition the SRS will define the users and
their respective characteristics as well as any constraints to development that
the team has identified.
The format of the SRS document will
address the overall project first- including functions and objectives in an
overview. This section will also address how this software interfaces with
other legacy systems and/or diagnostic equipment connected to it. Then the
subsequent sections will specifically addresses the components of the larger
software system. These sections delineate specifications for every facet of the
components design.
2.
Description of Project
2.1 Project Overview
Medical
records are the keystone to the healthcare profession; however these records
are not utilized to their fullest potential. Often records are inaccurate, misplaced,
and /or duplicated unnecessarily. In a world which recognizes the improvement
of data digitization and networking as a constructive force which often
increases efficiency while lowering costs; it is our view that medical records
networking could only benefit the quality of healthcare offered in the United
States.
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
FAT32 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, ECG, 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.1
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.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.
Note. This is a Medical
Information System therefore to limit access and ensure integrity of the data
only licensed medical personnel have access to input, search, and update
functions.
2.3.2
Nurse Administrators, Physician Office Administrators, System
Administrators and/or Therapists will have limited access and information
capabilities.
Note: For the reasons clearly stated in 2.3.1 the System
Administrator (or Vendor) will only be able to access data with his Admin
access code in combination with the Physician’s code while in the physician’s
presence.
2.4 Constraints to Project Development
and Implementation
2.4.1 The
Health Insurance Portability and Accountability Act of 1996 (HIPAA) has
mandated various standards on security, privacy, transaction and code sets, and
unique healthcare identifiers to which this system must adhere.
2.4.2 Legacy systems in place
must be considered and modified to interface with the new system design.
2.4.3 The timebox which
encapsulates the SDLC may limit some functionality of the system.
2.4.4 Both the hospital and
physician database will need large storage capabilities and a process to
archive outdated data.
(Note. Method and size of Database storage TBD)
2.4.5 Paper flat file medical
records will need to be produced and stored to ensure ability to handle
non-digitized medical professionals.
2.5 Assumptions and Dependencies
2.5.1 The system
relies on a Physician relationship with a hospital system with which he/she is
a staff member.
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.1
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.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.1.10 The software to be developed
shall display the correct time of day in compliance with ISO 8601. Reference 1.3.18
3.1.11 The software to be developed
must operate without interruption twenty-four hours a day.
3.1.12 The software must allow full and complete record search queries by
physicians; also allow access to limited bloodwork, medication, and allergen
information by EMT personnel and display results in order specified by
operator.
3.1.13 The software must allow input of
diagnostic imagery and FAT32 compression for storage and transmission of data.
3.1.14 The software must enable out put of real-time data and imagery from
electronic diagnostic equipment through java applets which run in the web
browser. Refer to 2.1
Note: Nurses at workstation or
doctors at desktop can access this data.
3.1.15 The software must retrieve and sort medical record information and allow
for screen and print output of said information.
Note. Print output will include name,
DOB, and requested diagnostic information only.
3.1.16 The software must encrypt the data using Rijndael (AES) encryption
algorithms from the
database for transmission from point to point.
3.2 Non- Functional Requirements of
Physician Digital Record System
3.2.1 The
software interface must follow design conventions which allow for familiar
location of drop down menus, help etc.
3.2.2 Input errors will be returned in red with
appropriate message box.
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 8 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.`1
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.1.8 The
software must only allow
deletions by the vendor and only after archiving data. Reference 2.4.4
4.1.9 The software to be developed
must display the correct patient name.
4.1.10 The software to be developed
shall display the correct time of day in compliance with ISO 8601. Refer to 1.3.18
4.1.11 The software to be developed
must operate twenty-four hours a day.
4.1.12 The software must allow full and complete record search queries by
physicians; also allow access to limited bloodwork, medication, and allergen
information by EMT personnel and display results in order specified by
operator.
4.1.13 The software must allow input of
diagnostic imagery and FAT32 compression for storage and transmission of data.
4.1.14 The software must enable out put of real-time data and imagery from
electronic diagnostic equipment through java applets which run in the web
browser.
Note: Nurses at workstation or
doctors at desktop can access this data.
4.1.15The software must retrieve
and sort medical record information and allow for screen and print output of
said information.
Note. Print output will
include name, DOB, and requested diagnostic information only.
4.1.16 The software must encrypt the data using Rijndael (AES) encryption
algorithms from the
database for transmission from point to point.
4.2 Non- Functional Requirements of
Hospital Digital Record System
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
ECG oscilloscope monitor.
5.1.4 The software to be developed shall display numeric output from an ECG
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 ECG values
at a remote location within five seconds.
5.2.3 The software to be developed must display a correct graphical ECG
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.
5.3 Real-time Patient Monitoring System
Performance Requirements
5.3.1 Acquisition of ECG
Data will require solid, wet gel, banana socket, snap or tab disposable electrode sensors.
5.3.2 Electrode (ECG) sensors will attach to electronic monitoring
equipment through 36 inch IEEE compliant universal lead wires. Refer to
Requirement 5.3.1
5.3.3 Pulse oximetry data must be collected using Masimo finger
sensor.
5.3.4 Masimo finger sensor must connect
to Masimo interface cable. Refer to Requirement 5.3.3
5.4 Design Constraints
5.4.1 Real-time Sensors and
Diagnostics may need to be simulated due to inability to access authentic
healthcare equipment.
5.4.2 Data Integrity and Security are life critical issues with this
system.
5.4.3 Redundant
power and transmission should be addressed as this system is life critical.
6. Specific Requirements of Ambulatory Medical System
6.1 Functional Requirements of
Ambulatory Medical System
(Note. Asked source about blood
type, allergies, etc. informed that information presently not relevant to EMT.
[1])
6.3.1 The software to be developed shall accept output from existing patient monitoring equipment.
6.3.2 The software to be developed shall display graphical and numeric data
at a remote location in real time.
6.3.3 The software to be developed shall graphically display output from an
EKG oscilloscope monitor.
6.3.4 The software to be developed shall display numeric output from an EKG
monitor.
6.3.5 The software to be developed
shall display numeric percentages from a pulse oximeter.
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
