This action might not be possible to undo. Are you sure you want to continue?
4 Predicted Evolution .2 In patient management 3.5 Pharmacy and lab facilities 6. Introduction 1. User requirements specification 3.2 Need for Additional Functionalities 6.3 Future Technologies 6. System evolution 6. Glossary 3. System architecture 4.1 Purpose 1.2 In patient management 5.1 General Maintenance and Evolution 6.1 New patient registration 3.4 Billing 5.2 Software requirements 5.3 Out patient management 5.TABLE OF CONTENTS 1.1 Registration 5.1 Hardware requirements 4.3 Out patient management 4.2 Scope 2. System requirements specification 5.
2. INTRODUCTION: This automated system is mainly provided to facilitate the easy management of the nursing home or the hospital. If needed. The user may be an administrator. billing 5.and billing details . nurse or a cashier.enables the growth of hospital 1. the date of discharge of the in patient .improves work efficiency 4.1 Purpose To provide an integrated solution for a hospital system which 1. the user should be trained up to use this module. This will include the type of the patient (inpatient/outpatient and corporate/individual). This system has to maintain the database of doctors working in the hospital and the patients who are treated in that particular hospital. pharmacy and lab facilities 1. This system includes the following scenario: 1. New patient registration 2.Doctor ‘s Database . The user will also have to select the laboratory tests done by the patient. It depends upon the particular hospital.enhances patient care 3. out patient management 4. The user will have to be familiar with the billing module. in patient management 3.1.helps in efficient management of the hospital 2. GLOSSARY HMS – Hospital Management System PDB – Patient Database DDB.2 Scope The user will enter the patient information .
2 Out Patient Management . The user may be an administrator. 3.3. USER REQUIREMENTS SPECIFICATION: . nurse or a receptionist. It depends upon the particular hospital.1 New Patient Registration 3.
2 In Patient Management 4. The GUI: The GUI for the system will be a should a one or two form main interface with separate smaller pop-up dialogs for interactions such as the registration as well as static forms for in patient and out patient management and billing . and/or radio buttons from that will allow the user to . 4.3. The main hardware requirements will be that of a ordinary system . SYSTEM ARCHITECTURE: 4.2 Software Requirements: The software requirements will be grouped into two categories: GUI and Computational Software. tabs. checks boxes.On each form will be an array of button.1 Hardware Requirements: Since this implementation is essentially a user interface. there will be little to no new hardware requirements.
To promote a platform independent application.2 out patient management Function Out patient management It manages the services provided to out patients Description Complaints Inputs Outputs Pre-condition Post-condition Destination History Diagnosis Advice Medicine Next visit Should be an existing patient None Add the details to the DB 5.customize the process of optimization and registration. SYSTEM REQUIREMENTS SPECIFICATION: 5.1 Registration Function Registration It provides each patient with a unique id for easy management Description The details of the patient Inputs Patient id Outputs Pre-condition Shouldn’t have already registered Post-condition Patient recognition card Add the details to the DB Destination 5. The fact that this code will most likely be in pre-compiled form upon delivery will eliminate the problem of portability. Computational Software: The code that will parse the latest course schedule and then perform the combinatorial mathematics on a set user selections to produces the optimized schedule will be written in ANSI C++. 5. this GUI will be written in JAVA.3 in patient management Function In patient management It deals with complete treatment and service to the patient Description Patient’s investigation report Inputs Patient’s daily report Outputs Pre-condition Patient should have registration id Post-condition Updation of the CSDB .
5 Pharmacy and lab facilities Function Pharmacy and lab facilities It notes down the cost and reports from lab and pharmacy Description Tests to be done and medicine prescription Inputs Lab reports and corresponding billing Outputs Pre-condition Test description and medicine prescription Post-condition Integration with billing Add details to DB Destination 6.4 Billing Function Description Inputs Outputs Pre-condition Post-condition Destination Add the details to the DB billing It provides bill details for both in and out patients List of service provided Payment receipt Completion of diagnosis Payment receiving Add the details to the DB 5. However. the system may be reconfigured for newer versions. supervised and possibly configured to operate efficiently for the hospital. The evolution of the HMS system depends heavily on the hospital’s future need for further computerized-assisted operations and newer technologies that may become available to the hospital. SYSTEM EVOLUTION: The hospital management system manage all the interactions between a patient and the hospital . .Destination 5.1 General Maintenance and Evolution After the system has been beta tested and configured for optimal performance. all computerized systems needs to be maintained. 6. We believe the functionalities of our current HMS project will satisfy the Hospital’s needs for efficient patient management . it provides easy use to the patients and helps the hospital in efficient management . Thus. system administrators monitoring the operational systems will give general feedback on desired usability and what they would like to see the system involve into.
which would not harm the functionality of this project. The patient and doctor management system will evolve around the availability of newer technologies. a new version of the system would be released to replace the existing registration system.4 Predicted Evolution The computer processing power and the Internet data transfer capability are likely to keep developing in the future. Computer software is always in a continuous life cycle of updates. HMS is entitled to four updated versions of the system to ensure product validity within the scope of operations defined in the Bid For Proposal. we predict a long lifespan of the product with the major adjustments in the front-end usability and further back-end configuration options for system administrators. The new hardware/software will either be compatible or not be compatible with the management system. 6. In this case.During the two first years of operations. configuration and amendments. uphold and improve the current standards.2 Need for Additional Functionalities The hospital may desire to add or change functionalities to HMS or configure the parameters for the optimization process. the patient management system must be updated and renewed at various times.3 Future Technologies The proposed registration and management system will provide the hospital with greater performance and simplicity of patient management. Newer technological breakthroughs affect the management system in one of two ways. and is most likely to. This may include adding functionalities like online appointment scheduling or consultants enquiry or change in the billing modes of payment . 6. The Internet infrastructure will allow the appointment scheduling system to become the most effective and beneficial computer assisted tool at PEC. New computer platforms will rather enhance the usability and efficiency of the system. Like most other Hospital tools and utilities. . Future technologies could. the same ideal that sparked the idea for the current HMS registration system. Therefore. 6.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.