Development of Hospital Management System
Disclaimer: This work has been submitted by a student. This is not an example of the work written by our professional academic writers. You can view samples of our professional work here.
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
Published: Wed, 28 Feb 2018
Hospital Management is a web based application to manage the activities related to doctor and patient. Hospital Management is based on distributed architecture. This involves the web services which receives request from the web based application and service processes the request and sends the response back to the application. Web services performs the database operations like insert, delete and update the information about the patients, doctors etc. This kind of distributed architecture is called as Service Oriented Architecture (SOA). This application contains login form, patient registration, doctor registration. Hospital Management application allow patients to edit their information like patient name, contact number, address, disease from which he is suffering from etc.
The concept of hospital management is very big. The scope of hospital management involves different modules like login module, patient info, doctor info, billing module, registration module and administration module. Login module will include the operation related to login, forgot password, password change, sending confirmations or alerts etc. Patient info module will include the details about the patient like patient history about his treatment and doctors involved in the treatment, details of medicines suggested by doctors. Billing Module will include the details of fees, mode of payment used by the patient to pay the fees. Registration module will allow the users to register their profiles. Administration module allows performing operations like creating the new users, performing password change operations, loading the information of doctors for the first time. Hospital Management uses sql server 2005 as the backend. The database is maintained on the remote server, this database holds all the information related to the hospital.
Before SOA architecture, DCOM or (ORBs) object request brokers based on CORBA specifications were used to develop the distributed applications. DCOM is known was distributed component object model. DCOM is an extension of COM (component object model), DCOM was released in 1996. It works primarily with Microsoft windows. It will work with Java Applets and ActiveX components through its use of COM.
Service Oriented Architecture is nothing but collection of services. These services are deployed at different servers at different locations. These services communicate with each other to perform required operations. The communication can be simple data passing.
Service Provider: The provider will create the service using any technology like .net or java and publishes its information for accessing the outside world. The provider decides which service to be published and one service can provide multiple operations, how to price the services or without charge like free services. Provider also decides the category of the services. The most common broker service is UDDI (Universal Description Discovery and Integration) provides a way publish and discover the information about the services.
Service Requester: The requester identifies the services using UDDI or any other service broker. The services provide the required operations then the requester should take it to the service provider for contract. Then requester can bind the services to the application and execute to get the required information.
The principles used for development, maintenance and usage of SOA are
- Reuse, comparability, granularity and interoperability.
- Identifying the services and categorizing them.
- Monitoring and tracking.
The specific architectural principles of SOA design are
- Service loose coupling
- Service encapsulation
- Service contract
- Service abstraction
- Service reusability
- Service discoverability
PROJECT SCOPE AND OBJECTIVE:
Development of a computerized Hospital management system with the provision of flexible, accurate and secured access to data thus bringing in the highly useful end product for the users as well as for the management.
- To develop a system that maintains a sophisticated Hospital management details bringing out the flexibility and the ease with which the users can use it.
- To track and improve internal performance of the financial corporation thereby allowing the flexible and secured transactions to happen.
FEATURES OF THE CURRENT SYSTEM
In the existing system the data required for the Hospital management is maintained in records. These are to be updated according to the requirements of the customer. It takes time to search for the required data. All the details regarding the hospitals and its timings are hard to maintain.
The work will be more so the systems need more number of crew to fulfill the requirements. There may be a chance of failure since it is manual. A simple fault of the system may lead to inconvenience and also cause a vast destruction. So these faults make the system less effective and performance of the system is very slow. Hence, there should be a system to overcome all these defects and provide the users with more facilities.
CHARACTERISTICS OF THE INTENDED SYSTEM
In the proposed system everything is computerized. The system provides all the details regarding the hospitals, its details, and soon. The users can search the required data easily within no time. A very less number of people are required to handle the system.
The patient’s need not wait for long time to fulfill his requirement. There is no chance of any failure in the system, which improves the performance of the system and also increases the efficiency of the system. Though this system is very beneficial a minor failure in the server or else the computer leads to a major loss of data.
The project performs the following functions
In 1997, a team of Medical Professionals has set up the first hospital, it signaled the dawn of a new era in medical care. At the heart of this movement was a burning desire to practice medicine with Compassion, Concern and Care, with a single-minded objective – the recovery of the patient. Today, with Multi-Specialty HOSPITAL across the state, and a reputation for humanitarian and selfless service of the highest order, Hospital enjoys an unbelievable amount of goodwill. A million smiles will bear testimony to that.
At hospital, we operate on a physician driven model. This means that all the main constituents of the CARE movement – the promoters, administrators and service providers are physicians. At the centre of the CARE model is the patient and the over-riding motive of all of Care’s activities is to provide quality medical care at an affordable cost. Technology, Training and Teamwork form the very core of the CARE model. We emphasize on a comprehensive and continuous education and training of every individual involved in patient care. Every effort will be taken to ensure that our growth is one decided by the patient’s needs, and not one decided by our corporate requirements.
Our hospital believes at:
- “A patient is the most important person in our hospital.
- He is not an interruption to our work; he is the purpose of it.
- He is not an outsider in our hospital. He is a part of it.
- We are not doing him a favour by serving him.
- He is doing us a favour by giving us an opportunity to do so.”
NEED FOR COMPUTERIZATION:
The use of computerized hospital is to provide effective facilities to the people, which are suffering from any problems. The advantages are:
- Less cost
- No mediators
- Excellent services
The main goal of this hospital management system is to achieve the people satisfaction. Hospital management system provides effective facilities to the people from any place in the world.
Software Requirement Specifications:
Operating Systems : Windows 2000 Prof
Database server : Sql Srver 2005
Programming Language : C#
Hardware Requirement Specifications:
Application Server Configuration:
Computer Processor : Pentium IV
Clock Speed : 700MHZ Processor
Hard Disk : 40GB
RAM : 256/512 MB
Modem : 56KBPS
Database Server Configuration:
Computer Processor : Pentium IV
Clock Speed : 700MHZ Processor
Hard Disk : 40GB
RAM : 256/512 MB
In the current system the data required is maintained in records. They are to be updated according to the requirements of the users. It takes time to search for the required query. All the details regarding the hospital and its patients are hard to maintain. The work will be more, so the system needs more number of crew to fulfill the requirements. There may be a chance of failure since it is manual. A one fault of the system may lead to inconvenience and also causes a vast destruction. So these faults make the system less efficient and performance of the system is very slow. Hence, there should be a system to overcome all these defaults and provide the users with more facilities.
In the current system if the user was suffering from any pain or etc heshe has no idea how to control the pain and suffering. Just they will be no idea for them and they become sicker and died more sooner And to know the availability for the treatment they have to go to hospital but mostly the government hospital doesn’t give more facilities to the patient as the patients want from the doctors. But in the case of the private hospital the patients has to pay more fares for the treatment and they do more delays in the case of the treatment they will be more formalities to be fulfil by the patients which take lot of time waste.
In the proposed system everything is computerized. The system provides all the details regarding the Hospital, doctors, patients, bed numbers, and fares also and so on. The user can search required data easily with no time. A very less number of staff is required to handle the system.
The patients need not wait for a long time to fulfil his requirement. There is no chance of any failure in the system, which improves the performance of the system and also increases the efficiency of the system.
Though this system is very beneficial a minor failures in the server or else the computer leads a major loss of data.
In preliminary investigation we got the result that the computerized Hospital management system is feasible. This includes following aspects.
Technical feasibility is nothing but implementing the project with existing technology. Computerized Hospital management System is feasible.
Economic feasibility means the cost of under taking project should be less than existing system Hospital management system is economically feasible, because it reduces the expenses in the manual system.
The .NET Framework is a new computing platform that simplifies application development in the highly distributed environment of the Internet. The .NET Framework is designed to fulfill the following objectives:
- To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely.
- To provide a code-execution environment that minimizes software deployment and versioning conflicts.
- To provide a code-execution environment that guarantees safe execution of code, including code created by an unknown or semi-trusted third party.
- To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments.
- To make the developer experience consistent across widely varying types of applications, such as Windows-based applications and Web-based applications.
- To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code.
.NET FRAMEWORK HAS TWO MAIN COMPONENTS:
The Common Language Runtime and the .NET Framework Class Library: – The common language runtime is the foundation of the .NET Framework. You can think of the runtime as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that ensure security and robustness. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code. The class library, the other main component of the .NET Framework, is a comprehensive, object-oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services.
The .NET Framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features. The .NET Framework not only provides several runtime hosts, but also supports the development of third-party runtime hosts.
For example, ASP.NET hosts the runtime to provide a scalable, server-side environment for managed code. ASP.NET works directly with the runtime to enable Web Forms applications and XML Web services, both of which are discussed later in this topic.
Internet Explorer is an example of an unmanaged application that hosts the runtime (in the form of a MIME type extension). Using Internet Explorer to host the runtime enables you to embed managed components or Windows Forms controls in HTML documents. Hosting the runtime in this way makes managed mobile code (similar to Microsoft® ActiveX® controls) possible, but with significant improvements that only managed code can offer, such as semi-trusted execution and secure isolated file storage.
The following illustration shows the relationship of the common language runtime and the class library to your applications and to the overall system. The illustration also shows how managed code operates within a larger architecture.
.NET COMPONENTS AND FEATURES:
Features of the Common Language Runtime:
The common language runtime manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime.
With regards to security, managed components are awarded varying degrees of trust, depending on a number of factors that include their origin (such as the Internet, enterprise network, or local computer). This means that a managed component might or might not be able to perform file-access operations, registry-access operations, or other sensitive functions, even if it is being used in the same active application.
The runtime enforces code access security. For example, users can trust that an executable embedded in a Web page can play an animation on screen or sing a song, but cannot access their personal data, file system, or network. The security features of the runtime thus enable legitimate Internet-deployed software to be exceptionally featuring rich.
The runtime also enforces code robustness by implementing a strict type- and code-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety.
In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common application errors, memory leaks and invalid memory references.
The runtime also accelerates developer productivity. For example, programmers can write applications in their development language of choice, yet take full advantage of the runtime, the class library, and components written in other languages by other developers. Any compiler vendor who chooses to target the runtime can do so. Language compilers that target the .NET Framework make the features of the .NET Framework available to existing code written in that language, greatly easing the migration process for existing applications.
While the runtime is designed for the software of the future, it also supports software of today and yesterday. Interoperability between managed and unmanaged code enables developers to continue to use necessary COM components and DLLs.
The runtime is designed to enhance performance. Although the common language runtime provides many standard runtime services, managed code is never interpreted. A feature called just-in-time (JIT) compiling enables all managed code to run in the native machine language of the system on which it is executing. Meanwhile, the memory manager removes the possibilities of fragmented memory and increases memory locality-of-reference to further increase performance.
Finally, the runtime can be hosted by high-performance, server-side applications, such as Microsoft® SQL Server™ and Internet Information Services (IIS). This infrastructure enables you to use managed code to write your business logic, while still enjoying the superior performance of the industry’s best enterprise servers that support runtime hosting.
.NET Framework Class Library:
The .NET Framework class library is a collection of reusable types that tightly integrate with the common language runtime. The class library is object oriented, providing types from which your own managed code can derive functionality. This not only makes the .NET Framework types easy to use, but also reduces the time associated with learning new features of the .NET Framework. In addition, third-party components can integrate seamlessly with classes in the .NET Framework.
For example, the .NET Framework collection classes implement a set of interfaces that you can use to develop your own collection classes. Your collection classes will blend seamlessly with the classes in the .NET Framework.
As you would expect from an object-oriented class library, the .NET Framework types enable you to accomplish a range of common programming tasks, including tasks such as string management, data collection, database connectivity, and file access. In addition to these common tasks, the class library includes types that support a variety specialized development scenarios.
ADO.NET IN CONNECTED MODE:
ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data sources exposed via OLE DB and XML. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, manipulate, and update data.
ADO.NET cleanly factors data access from data manipulation into discrete components that can be used separately or in tandem. ADO.NET includes .NET data providers for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, or placed in an ADO.NET Dataset object in order to be exposed to the user in an ad-hoc manner, combined with data from multiple sources, or remotes between tiers. The ADO.NET Dataset object can also be used independently of a .NET data provider to manage data local to the application or sourced from XML.
The ADO.NET classes are found in System.Data.dll, and are integrated with the XML classes found in System.Xml.dll. When compiling code that uses the System.Data namespace, reference both System.Data.dll and System.Xml.dll.
ADO.NET provides functionality to developers writing managed code similar to the functionality provided to native COM developers by ADO.
The most important change from classic ADO is that ADO.NET doesn’t reply on OLE DB providers and uses .NET managed providers instead. A .NET provider works as a bridge between your application and the data source. ADO .NET and .NET managed data providers don’t use COM at all, so a .NET application can access data without undergoing any performance penalty deriving the switch between managed and unmanaged code.
The most important difference between ADO and ADO.NET is that dynamic and Key set server -side cursors are no longer supported. ADO.NET supports only forward-only read-only result sets and disconnected result sets.
.NET Data Providers:
.NET data providers play the same role that OLE DB providers play under ADO, they enable your application to read and write data stored in a data source. Microsoft Currently supplies five ADO.NET providers:
OLE DB .NET Data Provider:
This provider lets you access a data source for which an OLE DB provider exists, although at the expense of a switch from managed to unmanaged code and the performance degradation that ensues.
SQL Server .NET Data Provider:
This provider has been specifically written to access SQL Server version 7.0 or later using Tabular Data Stream (TDS) as the communication medium. TDS is SQL Server’s native protocol, so you can expect this provider to give you better performance than the OLE DB Data Provider. Additionally, the SQL Server, .NET Data Provider exposes SQL Server specific features, such as named transactions and support for the FOR XML clause in SELECT queries.
ODBC .NET Data Provider:
This provider works as a bridge toward an ODBC source, so in theory you can use it to access any source for which an ODBC driver exists. As of this writing, this provider officially supports only the Access, SQL Server, and Oracle ODBC drivers, so there’s no clear advantage in using it instead of the OLE DB .NET Data Provider. The convenience of this provider will be more evident when more ODBC drivers are added to the list of those officially supported.
.NET Data Provider for Oracle:
This provider can access an Oracle data source version 8.1.7 or later. It automatically uses connection pooling to increase performance if possible, and supports most of the features of the Microsoft OLEDB Provider for Oracle, even though these two accessing techniques can differ in a few details—for example, the .NET Data Provider for Oracle doesn’t support the TABLE data type and ODBC escape sequences.
This DLL, which you can download from the Microsoft Web site, includes a few managed types that let you query and update a Microsoft SQL Server 2000 data source over HTTP. It supports XML templates, XPath queries, and can expose stored procedures and XML templates as Web services. The ODBC and Oracle providers are included in .NET Framework 1.1 but were missing in the first version of the .NET Framework. If you work with .NET Framework 1.0, you can download these providers from the Microsoft Web site. The downloadable versions of these providers differ from the versions that come with .NET Framework 1.1, mainly in the namespaces they use: Microsoft.Data.Odbc and Microsoft.Data.Oracle instead of System.Data.Odbc and System.Data.Oracle.
ADO.NET Object Model:
It’s time to have a closer look at the individual objects that make up the ADO.NET architecture illustrated in Figure 21-1. You’ll see that objects are divided into two groups, the objects included in the .NET Data Provider, and those that belong to the ADO.NET disconnected architecture. (In practice, the second group includes only the Dataset and its secondary objects.) Dataset (Disconnected data) .NET Data Provider Connection DataAdapter Command Data Reader ADO.NET Objects at a Glance
The Connection object has the same function it has under ADO: establishing a connection to the data source. Like its ADO counterpart, it has the Connection String property, the Open and Close methods, and the ability to begin a transaction using the Begin transaction method. The ADO Execute method isn’t supported, and the ADO.NET Connection object lacks the ability to send a command to the database.
The Command object lets you query the database, send a command to it, or invoke one of its stored procedures. You can perform these actions by using one of the object’s Executexxxx methods. More specifically, you use the ExecuteNonQuery method to send an action query to the database—for example, an INSERT or DELETE SQL statement—an Execute Reader method to perform a SELECT query that returns a result set, or an Execute Scalar method to perform a SELECT query that returns a single value. Other properties let you set the command timeout and prepare the parameters for a call to a stored procedure. You must manually associate a Command object with the Connection object previously connected to the data source.
The Data Reader object is the object returned by the Execute Reader method of the command object and represents a forward-only, read-only result set. A new row of results becomes available each time you invoke the Data Reader’s Read method, after which you can query each individual field using the Get Value method or one of the strongly typed Getxxxx methods, such as Get String or Get Float. Remember that you can’t update the database by means of a Data Reader object.
The Dataset object is the main object in the ADO.NET disconnected architecture. It works as a sort of small relational database that resides on the client and is completely unrelated to any specific database. It consists of a collection of DataTable objects, with each DataTable object holding a distinct result set (typically the result of a query to a different database table). A DataTable object contains a collection of Data Row objects, each one holding data coming from a different row in the result. A Dataset also contains a collection of Data Relation objects, in which each item corresponds to a relationship between different Data Table objects, much like the relationships you have between the tables of a relational database. These relations let your code navigate among tables in the same DataSet using a simple and effective syntax.
The DataAdapter object works as a bridge between the Connection object and the DataSet object. It’s Fill method moves data from the database to the client-side DataSet, whereas its Update method moves data in the opposite direction and updates the database with the rows that your application has added, modified, or deleted from the DataSet.
Whether you work in connected or in disconnected mode, the first action you need to perform when working with a data source is to open a connection to it.InADO.NET terms, this means that you create a Connection object that connects to the specific database. The Connection object is similar to the ADO object of the same name, so you’ll feel immediately at ease with the new ADO.NET object if you have any experience with ADO programming. Setting the Connection String Property the key property of the Connection class is Connection String, a string that defines the type of the database you’re connecting to, its location, and other semicolon-delimited attributes. When you work with the OleDbConnection object, the connection string matches the connection string that you use with the ADO Connection object. Such a string typically contains the following information,
- The Provider attribute, which specifies the name of the underlying OLE DB Provider, used to connect to the data. The only values that Microsoft guarantees as valid are SQLOLEDB (the OLE DB provider for Microsoft SQL Server), Microsoft.Jet.OLEDB.4.0 (the OLE DB provider for Microsoft Access), and MSDAORA (the OLE DB provider for Oracle).
- The Data Source attributes, which specifies where the database is. It can be the path to an Access database or the name of the machine on which the SQL Server or the Oracle database is located.
- The User ID and Password attributes, which specify the user name and the password of a valid account for the database.
- The Initial Catalog attributes, which specifies the name of the database when you’re connecting to a SQL Server or an Oracle data source. Once you’ve set the Connection String property correctly, you can open the connection by invoking the Open method:
ADO.NET in Disconnected Model:
In the preceding chapter, you saw how to work with ADO.NET in connected mode, processing data coming from an active connection and sending SQL commands to one.ADO.NET in connected mode behaves much like classic ADO, even though the names of the involved properties and methods (and their syntax) are often different. You’ll see how ADO.NET differs from its predecessor when you start working in disconnected mode. ADO 2.x permits you to work in disconnected mode using client-side static record sets opened in optimistic batch update mode. This was one of the great new features of ADO that proved to be a winner in client/server applications of any size. As a matter of fact, working in disconnected mode is the most scalable technique you can adopt because it takes resources on the client (instead of on the server) and, above all, it doesn’t enforce any locks on database tables (except for the short-lived locks that are created during the update operation).
The following Imports statements are used at the file or project level:
- Imports System. Data Imports System.Data.Common Imports System.Data.OleDb Imports System.Data.SqlClient Imports System.Data.Odbc Imports System.IO Imports System.Text.RegularExpressions
The DataSet Object Because ADO.NET (and .NET in general) is all about scalability and performance, the disconnected mode is the preferred way to code client/server applications. Instead of a simple disconnected recordset, ADO.NET gives you the DataSet object, which is much like a small relational database held in memory on the client. As such, it provides you with the ability to create multiple tables, fill them with data coming from different sources, enforce relationships between pairs of tables, and more.
The DataSet object is central to supporting disconnected, distributed data scenarios with ADO.NET. The DataSet is a memory-resident representation of data that provides a consistent relational programming model regardless of the data source. It can be used with multiple and differing data sources, used with XML data, or used to manage data local to the application. The DataSet represents a complete set of data including related tables, constraints, and relationships among the tables.
The DataAdapter object, which works as a connector between the DataSet and the actual data source. The DataAdapter is in charge of filling one or more DataTable objects with data taken from the database so that the application can then close the connection and work in a completely disconnected mode. After the end user has performed all his or her editing chores, the application can reopen the connection and reuse the same DataAdapter object to send changes to the database. Admittedly, the disconnected nature of the DataSet complicates matters for developer
Cite This Work
To export a reference to this article please select a referencing stye below: