Documente Academic
Documente Profesional
Documente Cultură
APPLICATION DEVELOPMENT – II
Of
Master of Science
in
Information Technology
By
Neraja Venugopal
1|Page
Table of Contents
1. Introduction……………………………………………………………………………………3
1.1 Purpose………………………………………………………………………………………...3
1.2 Scope of Document……………………………………………………………………………3
1.3 Definitions, Acronyms, and Abbreviations…………………………………………………...3
1.5 Overview of document………………………………………………………………………...4
2. Description of Project…………………………………………………………………………4
2.1 Project Overview……………………………………………………………………………...5
2.2 Project Functions……………………………………………………………………………...6
2.3 User Characteristics…………………………………………………………………………...9
2.4 Constraints to Project Development and Implementation…………………………………….9
2.5 Assumptions and Dependencies………………………………………………………………9
3. Physician Office System……………………………………………………………………..11
3.1 Logical Database Requirements……………………………………………………………..11
3.2 Design Constraints…………………………………………………………………………...11
4. Hospital System………………………………………………………………………………12
4.1 Hospital Digital Record System Performance……………………………………………….12
4.2 Logical Database Requirements…………………………………………………………......12
4.3 Design Constraints…………………………………………………………………………...13
5. Real-time Patient Monitoring System……………………………………………………....12
5.1 Functional Requirements of Real-time Patient Monitoring System…………………………12
5.2 Non- Functional Requirements of Real-time Patient Monitoring System…………………...12
5.3 Real-time Patient Monitoring System Performance…………………………………………13
5.4 Design Constraints…………………………………………………………………………...14
6. Ambulatory Medical System………………………………………………………………...14
6.3 Real-time Ambulatory Medical System Performance……………………………………….14
6.4 Design Constraints…………………………………………………………………………...14
7. Design of Architecture……………………………………………………………………….14
7.1 Design Concept………………………………………………………………………………14
7.2 Data Integration……………………………………………………………………………...15
7.3 Function Integration………………………………………………………………………….16
8. Workflow Design……………………………………………………………………………..17
9. Feasibility Study……………………………………………………………………………...20
9.1 Technical Feasibility……………………………………………………………………........21
9.2 Economical Feasibility……………………………………………………………………....22
9.3 Operational Feasibility………………………………………………………………...…….22
9.4 Schedule Feasibility……………………………………………………………...………….23
References……………………………………………………………………………………....25
2|Page
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.
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.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.
3|Page
1.3.4 Diastolic blood pressure. The pressure at which the heart’s aortic valve closes.
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.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.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.
4|Page
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
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]
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.
5|Page
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, 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.1
6|Page
Hospital
Database
Physician’s
Office
Record Record
input retrieval
Record retrieval
Streaming Software to
DataFlow Record input/
be developed
Query
Query
Record input/
Query
Record retrieval
Real-time
Patient EMT
Monitor
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
7|Page
«extends»
Uses Diagnotics Patient
«extends»
«uses»
Physician Database
«extends»
Physician «uses»
Patient Interface
«extends»
Software TBD
«extends»
Stores
«uses» «uses»
«extends»
-Access Data Structure
Updates
Hospital Database
Hospital Healthcare Interface *
«uses»
* *
«uses» Retrieves
«uses» -Recieves Data -Transmits Data
Sorts
Real Time Monitor
«uses»
EMT Transmits
*
Maintains
«uses» -Data Maintenence
«extends»
System Administrator
Administrative Interface
8|Page
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.
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.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.
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.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.
9|Page
Model Driven System Development Life Cycle
MDD
Preliminary
Investigation
MDD
Problem
Analysis
MDD
Requirements
Analysis
MDD
Decision
Analysis
Physician/ Hospital Data Repository Real-time Patient Monitor
Wireless EMT Connection
MDD
Subproject Integration
and
Full-System Implementation
10 | P a g e
3. Physician Office System
PK oOfcAdminId
tblTranscriptionist
oOfcAdminPsw
PK trMdRcTranID
oPaymentDue
trMdRcTranName
oNextApp Is cross-checked/receives chart
oBalance
Generates/is assigned
PK pPatientID_oOfcAdminID
cChrgeAmt tblTreatment
cServiceName
PK rxTreatmentID
tblMedicalRecord rxTreatmentName
rxMedication
PK rMedRecID rxGeneralInstruction
pPatientID
Presented to/ paid by rxDosage
rxFollowupCare
rFamilyHistory
rAllergies
rSurgicalHistory
rMedications tblPatient
Requires/will remedy
rPresentConditions
PK pPatientID
Associated with/ discusses
rApptHistory
pFirstName
pLastName
Generates data/ is validated pMiddleInitial tblDiagnosis
pBirthDate PK dDiagnosisID
pInsName
pInsID dDiagnosisName
pPhone
pEmail
pStreetAddress
pCity
pState
pZip
pPatientPsw
Patient_n tblPatient_d
PK pPatientID_nNurseID PK pPatientID_drDrId
Formulates/ is made by
pTodayBp pTodaySymptom
pTodayTemp
Is checked/is observed by
Is checked/is observed by
tblNurse tblDoctor
PK nNurseID PK drDrID
11 | P a g e
4. Hospital System
4.1.2The Hospital software should support an internet server, diagnostics inputs (see section
.5.1), thirty two terminals and a SQL server database.
4.1.3 95% of the transactions shall be processed in less than one second.
4.1.5 Power supply should have a back up and a disaster recovery plan.
4.1.7 Secure Socket Layer 3.0 with 128 bit encryption will enable network security
5.1.2 Electrode (EKG) sensors will attach to electronic monitoring equipment through 36 inch
IEEE compliant universal lead wires. Refer to Requirement 5.3.1
5.1.3 Pulse oximetry data must be collected using Masimo finger sensor.
5.1.4 Masimo finger sensor must connect to Masimo interface cable. Refer to Requirement
12 | P a g e
5.2 Design Constraints
5.2.1 Real-time Sensors and Diagnostics may need to be simulated due to inability to access
authentic healthcare equipment.
5.2.2 Data Integrity and Security are life critical issues with this system.
5.2.3 Redundant power and transmission should be addressed as this system is life critical.
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.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.
13 | P a g e
6.4.5 The software to be developed must operate twenty-four hours a day.
TBD
TBD
7. DATA DESIGN
The complicated digital hospital environment could beconsidered as a digital neural network
system, as depicted inThe outmost ring, analogous to neural end, contains theterminals,
workstations, medical devices and even sensors in the hospital, through which all kinds of end-
users could interface with the system. The end-users do not need to be aware of the internal
structure of system at all. The middle ring, assimilated to peripheral neural system, contains all
kinds of the medical information systems, through which most of the tasks in a hospital are
accomplished. Among them, some are departmental systems such as PACS, RIS and LIS, while
others are enterprise systems such as HIS. Since most of the systems come from different
vendors, they are often heterogeneous and isolated. In order to fulfil the digital workflow among
these systems, a kind of framework or model is necessary to specify how to exchange
14 | P a g e
messages among these systems to achieve the workflow integration. Proceedings of the 2005
IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China,
September 1-4, 2005 0-7803-8740-6/05/$20.00 ©2005 IEEE. 6957 Digital neural network
system in hospital The central ring, assimilated to central neural system, is the core of Enterprise
Hospital Information System, which contains a “virtual” data center and a set of middleware
components interfacing with the systems in the middle ring and the terminals in the outmost ring.
The word “virtual” means that other than archiving all clinical data itself, the data center actually
manages all data through linkage to the real data records distributed in different systems. The
middleware components are based on web service, a middleware architecture using Simple
Object Access Protocol (SOAP). The standard interfaces for each service are defined to provide
common functionalities, and support Enterprise Viewers (See Fig.2).
With more and more systems being introduced into hospital, a key problem is how to keep an
integrated data set. To keep all clinical data in one storage seems to be a good solution, but due
to the large quantities of clinical data and the complexity to unify all data from heterogeneous
systems, it proves to be effective only in small hospitals or newly-built hospitals. In the
architecture, the concept of “virtual” data center has been introduced. The clinical data are
distributed and archived in corresponding departmental systems or enterprise systems. The data
center stores the linkage information of each data record in different heterogeneous
15 | P a g e
The architecture of Enterprise Hospital Information System
Systems, thus functioning as a “virtual” data center for all clinical data. The data records stored
in the actual data center are 6W1H (Who, When, Where, toWhom, What, Why, How)
information for the clinical events. To be ideal, any event, as long as it happens in the clinical
environment, it should be recorded, including making clinical report, injecting medicine to a
patient and measuring body temperature for a patient, to name a few. For an example, when a
radiologist makes a report, the information of the radiologist who makes the report (Who), the
time and the department of the report (When & Where), the patient whom the report belongs to
(toWhom), the event type of the report (What), the event of the radiology order of the report
(Why), the report status of creating, editing or confirming (How), and the data link of the report
are recorded.
Compared to the data structure based on patient or visit, 6W1H data structure is more flexible
and could be used for different requirements of data view such as the patient record view (the
events happened on the patient), the doctor task view (the events initiated by the doctor), and
even the process management view (the events linked each other by the “Why” element).
According to the practical situation of each existing system, the event recorded could be either
cursory if the system is difficult to be expanded or in detail if the system could be tailored.
Hospitals have a strong need for affordable, interoperable information systems. These systems
must operate seamlessly across a wide variety of institutions pharmacies, laboratories, physician
practices of all sizes, outpatient clinics, community hospitals, and tertiary/quaternary care
regional medical centers. They have many operations (methods) in common across the clinical
departments. In the architecture, these common operations are realized as a set of web services
on an enterprise basis to implement the function integration. 1) Data Registry Service: In order to
16 | P a g e
implement the “virtual” data centre, it’s necessary for all medical information systems to register
the data through the Data Registry Service to the actual data server wherever and whenever the
clinical event happens through the Data Registry Service. The systems must at least register the
data linkage information to the data center while the data record is created, deleted and updated.
The schema of storage has the good expansibility since new systems are easier to be merged into
the architecture by complying with the interface of Data Registry Service. 2) Patient
Identification (ID) Service: Throughout an individual’s lifetime they may have episodes of care
provided by healthcare organizations. When a patient comes into a healthcare organization for
care there is a need to find the records for any previous care. Each system may have 6958 used a
different scheme (e.g. numbering system) to identify the patient. It is desirable to combine the
medical records from multiple institutions in order to show a complete picture of a person’s
health record. One of the major impediments to this sharing of patient records between
organizations is a lack in the ability to identify a patient in a consistent manner. Due to this
inability Patient ID Service specifies the common interfaces that allow multiple systems to
interoperate.
8. WORKFLOW DESIGN
Data integration is oriented to create the “virtual” datacenter to manage the entire distributed
clinical data, while function integration is oriented to provide common functionalities for
systems in healthcare institutions. None of them focus on the workflow, which is a technology
that manages and monitors processes and allows the flow of work between individuals and/or
departments to be defined and tracked. It is usually implemented by the data relationship of the
database in the client-server model. But in a distributed environment such as a healthcare
institution, the implementation will be more complicated. Middleware technologies such as Web
Service could be used to implement the digital workflow by tackling with distributed database
environment just like one database in client-server model. But it has no expandability in terms of
adding new system into the architecture especially when the data structures are unknown.
Standard messages such as DICOM and HL7 have already been applied in many systems to
implement the workflow between different systems, but a complete integration is
17 | P a g e
still difficult if there is no framework or model to guide the system to exchange the correct
message in correct time. IHE is an initiative designed to stimulate the integration of information
systems that support modern healthcare institutions. Using a common framework, IHE employs
existing protocols like DICOM and HL7 to connect devices, terminals and information systems
in a hospital so as to fulfill the digital workflow. Up to now, it contains 12 integration profiles for
radiology technical framework each of which specifies the model of one clinical application
environment. Fig.3 depicts the Scheduled workflow integration profile. The Scheduled
Workflow Integration Profile establishes the continuity and integrity of basic departmental
imaging data acquired in an environment where examinations are being ordered. It specifies a
number of transactions that maintain the consistency of patient and ordering information as well
as defining the scheduling and imaging acquisition procedure steps. There are actually four
different systems involved, corresponds to ADT and Order Placer actors, RIS corresponds to
DSS/Order Filler and Performed Procedure Step Management actors, PACS corresponds to
Image Manager, Image Archive, Image Display and Evidence Creator actors, Modality
corresponds to Acquisition Modality actor. By implementing each system with the standard
transactions, we could easily achieve the workflow integration.
18 | P a g e
Design concept of Enterprise Viewers
19 | P a g e
Clinical implementation of the first two phases
E. Enterprise Viewer
Now that we could access all clinical data through the schema of the “virtual” data center, the
key is how to organize and present them in an appropriate way so that the data could be fully
utilized. Enterprise Viewer Services achieve this goal by reorganizing the entire clinical data set
and projecting the specialized view for users of each role. Included are Physician’s View,
Clinical Specialist’s View, Patient’s View, Department Manager’s View, Senior Executive’s
View, and IT Manager’s View
9. Feasibility Study
Depending on the results of the initial investigation the survey is now expanded to a more
detailed feasibility study. “FEASIBILITY STUDY” is a test of system proposal according to
its workability, impact of the organization, ability to meet needs and effective use of the
resources. It focuses on these major questions:
1. What are the user’s demonstrable needs and how does a candidate system
meet them?
2. What resources are available for given candidate system?
3. What are the likely impacts of the candidate system on the organization?
4. Whether it is worth to solve the problem?
20 | P a g e
During feasibility analysis for this project, following primary areas of interest are to be
considered. Investigation and generating ideas about a new system does this.
Steps in feasibility analysis
21 | P a g e
Front-end selection:
It must have a graphical user interface that assists employees that are not from IT
background.
1. Scalability and extensibility.
2. Flexibility.
3. Robustness.
4. According to the organization requirement and the culture.
5. Must provide excellent reporting features with good printing support.
6. Platform independent.
7. Easy to debug and maintain.
8. Event driven programming facility.
9. Front end must support some popular back end like Ms Access.
According to the above stated features we selected VB6.0 as the front-end for
developing our project.
Back-end Selection:
The technical feasibility is frequently the most difficult area encountered at this stage. It is
essential that the process of analysis and definition be conducted in parallel with an assessment
to technical feasibility. It centers on the existing computer system (hardware, software etc.)
and to what extent it can support the proposed system.
22 | P a g e
9.2) Economical feasibility
Economic justification is generally the “Bottom Line” consideration for most systems.
Economic justification includes a broad range of concerns that includes cost benefit analysis.
In this we weight the cost and the benefits associated with the candidate system and if it suits
the basic purpose of the organization i.e. profit making, the project is making to the analysis
and design phase.
The financial and the economic questions during the preliminary investigation are
verified to estimate the following:
The cost to conduct a full system investigation.
The cost of hardware and software for the class of application being considered.
The benefits in the form of reduced cost.
The proposed system will give the minute information, as a result the performance is
improved which in turn may be expected to provide increased profits.
This feasibility checks whether the system can be developed with the available funds. The
Hospital Management System does not require enormous amount of money to be developed.
This can be done economically if planned judicially, so it is economically feasible. The cost of
project depends upon the number of man- hours required.
The system is operationally feasible as it very easy for the End users to operate it. It only
needs basic information about Windows platform.
23 | P a g e
9.4) Schedule feasibility
Time evaluation is the most important consideration in the development of project. The time
schedule required for the developed of this project is very important since more development
time effect machine time, cost and cause delay in the development of other systems.
A reliable Hospital Management System can be developed in the considerable amount of time.
24 | P a g e
References
[1] Mack, Francis E. MD, Personal Interview February 1, 2003
25 | P a g e