View with images and charts Designing a Computer Aided Hospital Management System: Management Information Systems (MIS) INTRODUCTION Hospital management and business processes in hospitals have changed considerably over the previous years, as did the use of Information Technology (IT) in their daily works. It was found in our analysis that the use of IS in the hospitals did not develop according to the needs and developments in the hospital organizations over the past decade. Health care in Bangladesh, as in many other countries, is confronted with a growing demand for medical treatments and services, due to factors such as, a ‘growing’ population, and higher individual standards for quality of life. This work is focused on the development of a computer aided Hospital Management System and specifically on hospital information systems (IS). An interesting question is how organisational, managerial and IT developments take place in hospitals, and how these developments influence each other, in terms of impact, alignment, and reinforcement. Modern hospitals nowadays supply professional services, in stead of products. Hospitals had a high cost technological infrastructure in order to sell medical services. This organisational type is now under pressure, due to the changes in society, politics and population. Hospitals can respond to these pressures by transforming into ‘functional specialization’. In this way the organisation tries to reduce costs and to improve the quality of specialized medical services. A more recent response of hospitals is to move into ‘network management’. A networked hospital tries to improve it's 'input-output' or 'market' relations with primary care physicians In our study, hospital management people have indicated that technology can substantially influence hospital activities and services. It is also expected that health care costs will depend significantly on sophisticated patient management and diagnosis operations. The use of IT in diagnostics and treatment processes will add to the development of networks of clinical, hospital and health care processes. Until recently, in Bangladesh, the focus of IT in health care was on personnel, logistics, and finance. In our proposed solution, we focused on the care processes, including electronic medical files and quality management of patients. It is expected that the older information systems will become more integrated with the new one, the primary process oriented applications of IT. 1.1
Objectives The general objective is designing a Computer Aided Hospital Management System, an integrated Hospital Information System which addresses all the major functional areas of modern multi-specialty hospitals. Our specific objectives of the project are as follows – • • • •
To design a system for better patient care. To reduce hospital operating costs. To provide on demand MIS report to management for better decision making. To streamline activities for better co-ordination among the different departments.
• • •
To provide top management a single point of control. To learn the process of developing an Information System. To explore new IS technologies and use them, if appropriate.
1.2
Methodology We divided our tasks in eleven sections as following: Task One: Collect data and information Task Two: Analyse business processes Task Three: Define business process Task Four: Explore New Technology Task Five: Draw data flow diagram Task Six: Determine Entities Task Seven: Determine Identifier for each entity Task Eight: Draw E/R diagram Task Nine: Derive relational schema from E/R diagram Task Ten: Add anticipated attributes Task Eleven: Create Data Dictionary
1.3
Data and its source We have collected data from IBN-Sina Hospital, Bangladesh Medical College and Hospital, Central Hospital and Holy Family Hospital.
1.4
Review of the literature and justification for this project. Some hospitals in our country are using software for their management information systems, but we found that they have some limitations, like patient history is not stored in database, no online facility for appointments, scalability of user access is limited, etc. We have tried to introduce a new technology of Web based Services which is the most exciting technology in today’s market and is the most current tool for enabling distributed computing. In Chapter 4, we have discussed the history of distributed computing, the concepts and protocols of web services, and the main applications for web services. Hospital management systems constitute an excellent area for MIS development. There are couple of reasons to use the hospital management system. We tried to develop a computer-aided system that enables better patient care, patient safety and helps to reduced management costs. Our solution provides easy access to critical information, thereby enabling management to take better decisions on time and it provides benefits of streamlining of operations, enhanced administration and control, improved response, cost control and improved profitability.
1.5
Limitation A typical hospital management system, which covers all functional areas, is large enough. In our short project period it was difficult to develop all system components. Thus we decided to reduce the size of our systems in the design phase. We have designed only operational activities of a typical computer aided hospital management systems.
2.1 Organizational Chart
H o s p it a l M a n a g e m e n t C h a ir m a n D ir e c to r M e d ic a l S e r v ic e
C o n s u lt a n t s P h y s ic ia n s , S u r g e o n s A n a e s t h e t i s t s , R a d i o lo g i s t s e t c .
L a b S e r v ic e
D ir e c to r F in a n c e a n d A d m in is t r a tio n
M e d ic a l M a n a g e r
R a d io g r a p h y
W o r k s a n d M a in t e n a n c e
F ro n t D e s k
H o s p ita l E n g in e e r s
H o s p ita l S e c r e ta r ie s
P h a rm a c y
2.2 Hospital Business Process
Business Process Hospital Division Indoor Operation
Health Care Service Division
Outdoor Operation
Support Service Division
Managed Care Investigative Labs
Primary HealthCare Diagnostic Center Drug House Service
2.3
Hospital Business Process: Patient Management In the process of Patient Management, our observation found the following activities: • Pre-Admission Procedure • Admission • During Stay • Going Home • Financial Information
Figure 1: Hospital Business Process: Patient Management
2.4 The Difficulties System Integrations System integration is always an issue for any system, especially for systems developed for the hospital business. In our case, the system of the Hospital needs to communicate with different systems from different module, to collect information about the schedules and investigation reports. In most cases, system developers need to customize the proxies applied to each other system, which evolves tremendously efforts on programming. It also dramatically raises the cost of integrations while we integrate systems case by case. Scalability, Security, and Transaction Management Security is important issue while developing an enterprise application. Traditionally, developers have been able to maintain a relatively high level of control over the environment of both servers and clients. However, for scalable web-accessible applications, information assets are projected into less-protected environments, and it becomes increasingly important to maintain tight security over the most sensitive assets, while allowing seemingly unencumbered access to others.
Transactions management is also a complicate, but necessary issue for any enterprise system. To maintain the integrity and consistency of the data, a system need to ensures that each unit fully completes without interference from other processes. If the unit can be completed in its entirety, it is committed. Otherwise, the system completely rolls back. 2.5 The Solutions 3-Tier Client-Server Architecture Our proposed system is based on 3-Tier Client-Server Architecture. In this architecture, the presentation, the application processing and the data management are logically separate processes. A 3-tier architecture does not necessarily mean that there are three computer systems connected to the network. A single server computer can run both the application processing and the application data management as separate, logical servers. However, if demand rise, it is relatively straightforward to separate the application processing and the data management and execute these on separate processes. The application processing is the most volatile part of the system and it can be easily updated because it is centrally located. Processing, in some cases, may be distributed between the application logic and the data management servers, thus leading to more rapid response to client requests.
Presentation
Server
Server
Application Processing
Data Management
Figure 2: A 3-Tier clientserver architecture J2EE and .NET are both based on the concept of 3-Tier Architecture. The goal is that the construction and delivery of the user interface is separate from the construction of the business logic, which in turn is separate from the backend data or infrastructure being accessed. This type of architecture depends upon a middle tier container providing a number of services to enable scalability, reliability and availability. Depending on the implementation, the container typically offers a rich set of services for security, transactions and connectivity. Both J2EE and .NET architectures provide developers with this core infrastructure rather than requiring them to build it. In our proposed systems we suggest to use .NET architecture with backend RDMBS Microsoft SQL Server. But alternate option J2EE can be used, we leave this choice to user. Web Services for System Integrations This is the era of distributing computing. Before designing any enterprise application, interoperability should be considered. There will be a time come, when a hospital require to communicate with various systems such as internal financial data, international health care organization, association of health care, potential customer etc. In that case we suggest to use Web Services. Web Services are module
Client
applications that adopting some language natural protocols, which can be published, located, and invoked through the Internet. One of the reasons that web service is a solution for system integration is the broad acceptance of this technology. Major vendors in the market including Microsoft, IBM, BEA, Sun Microsoft, Oracle…. all agree with web service protocols and implement them in their products. Another major reason for adopting web services is the simplicity of these protocols. These XML based protocols are easy to use, and easy to attach on existing system that sometimes businesses don’t even need to change a line of code for the existing system. [Detail web service dealt la SYSTEM ANALYSIS AND IMPLEMENTATION 3.1 Hospital Management System In our study, we tried to design a solution for hospital management which are capable to handling the activities of following major departments: 1. Outdoor patient's Department 2. Indoor Patient's Department 3. Investigative Labs 4. Billing 5. Medical Stores 6. Financial Accounting 7. Payroll 3.1.1 Hospital Management System – Patient Registration The Patient Registration System, which captures complete and relevant patient information. The system automates the patient administration functions to have better and efficient patient care process. • • • • • • • •
Patient Registration Details Inpatient and Outpatient Registration Medical Alerts Details Appointment Scheduling (Patient / Doctor wise) Doctor's Schedule Summary Doctors Daily Schedule List Patient Visit History Appointments for Radiology tests and Operation Theatre
It provides for enquiries about the patient, the patient's location, admission, and appointment scheduling and discharge details. Furthermore, this system even takes care of package deals for a patient for a fixed cost. Medical Record keeps an abstract of clinical data about patients. It allows easy retrieval of medical records on patients. 3.1.2 Hospital Management System - Billing The Patient Billing module handles all types of billing for long-term care. This module facilitates cashier and billing operations for different categories of patients like Outpatient and Inpatient. It provides automatic posting of charges related to
different services like bed charges, lab tests conducted, medicines issued, consultant's fee, food, beverage and telephone charges etc. The system is tuned to capture room and bed charges along with ancillary charges based on the sponsorship category. The Billing Screens is used for In-patient and Outpatient Billing and invoicing. Further more the charges for various services rendered can be recorded through service module and this can be used for billing purposes. • • • •
Payment Modes / Details Patient Billing Details Automatic Room and Board Charges Extensive Third-party Billing
The system supports multiple reports utilizing various print options with user-defined parameters. 3.1.3 Hospital Management System - Financial Accounting The Financial Accounting Module deals with Cash/Bank, Receipt/Payments, Journal Voucher and General Ledger etc. Books like Cashbook, Bankbook and Ledger book can be generated. This module generates reports like Trail Balance, Balance Sheet and Profit and Loss statement. The Financial Accounting Screens describe about the Account Payable, Account Receivable and General Ledger. Also describe the activities related to IP, OP, Bank related activities and provision to clearing the Supplier Invoice and keep track of the Account Receivable and Revenue related activities. The services that are covered by the sponsor companies, Insurance Agencies, Family Accounts, Individual Accounts, sponsorship details of the patient, Health Card Insurance are recorded in the system. 3.1.4 Hospital Management System - Payroll The Payroll & Personnel module deals with Pay (and deduction) calculation, printing of salary slip, salary certificates, and PF statements, Gratuity Statement and provides a monthly analysis. It deals with the maintenance of employee bio-data, Attendance / Overtime details. It also reports on absenteeism, leave encasements etc. The Personnel & Payroll department is responsible Employee Related Activities like appointing the staff, maintaining the employee database, Fixing allowances and deductions, Leave entitlements, Leave sanctions, Loan, Termination Process, Maintenance of Hospital documents, Insurance details, Tenancy Contracts and Vehicle Registration etc. This module is not included in our current version. 3.1.5 Hospital Management System - Outpatient Management The Outpatient module serves as an entry point to schedule an appointment with the Hospital Resident Doctor or Consultant Doctor for Medical Consultations and diagnosis. This module supports doctors to take better and timely consultation decisions by providing instant access to comprehensive patient information. Patient visits are divided into various status. This module also handles requests and results of laboratory tests and other examinations. External Doctors visit to in patients can be defined as "Call on". Some patients may avail only the hospital facilities like Lab, Radiology, Nuclear Medicine, and Physiotherapy and so on. •
Medical Alerts Details
• • • • • • • • •
Consultation Duty Roster Diagnosis Details Patient's Appointments Daily / Weekly Schedule Summary Appointment Scheduling / Rescheduling Facility Outpatient Medical Observation Details Investigation / Treatment History Clinical Service Details Doctor's Diagnosis Statistics
Further more, Confidentiality of Doctors Observation, Previous History of Patients Visit, Online Prescription, Online Request for Investigations and so on, are the special features in Doctors Observation screen. This system calculates the cost for the services rendered to the patient and reflects in the billing module appropriately resulting in smooth billing process. 3.1.6 Hospital Management System - Inpatient Management The inpatient module is designed to take care of all the activities and functions pertaining to Inpatient Management. This module automates the day-to-day administrative actives and provides instant access to other modules, which leads to a better patient care. It provides comprehensive data pertaining to Admission of Patients & Ward Management: Availability of beds, Estimation, Agreement preparation, Collection of advance, Planned admission, Emergency admission and so on. The Inpatient module also deals with Ward Management: Shifting from one ward to the other, Bed availability, Surgery, Administration of drugs, nursing notes, charge slip and so on. • • • • • • • •
Admission Cost Estimation Doctor Transfer Details Nursing Notes Medical Observation Pending Drug Request Surgery Scheduling Details Discharge Notification Summary Expected Date and Time of Discharge
The module tracks every visit made by the patient and caters to follow-up visits of patients, along with multiple appointments. 3.1.7 Hospital Management System - Pharmacy Management Pharmacy module deals with the automation of general workflow and administration management process of a pharmacy. The pharmacy module is equipped with bar coding facility, which makes the delivery of medical items to the patient more efficient. This module deals with the activities such as: • • • •
Enquiry Purchase order Pharmacy drug configuration Pharmacy stores configuration
• • • • • • • • • •
Drug issue to patients and billing Supplier information Maintenance of drug inventory Purchase Requisitions Return of items nearing expiry Destruction of expired items Physical stock verification and adjustment Goods receipt Stock Adjustment Stock in Hand reports
In addition the Online prescription facility assists and facilitates the physicians to track the patient's prescription details and as well reflects the medication billing details in the Billing module. 3.1.8 Hospital Management System – Laboratory Management The Laboratory module automates the investigation request and the process involved in delivering the results to the concerned department/doctor of the hospital. Laboratory module starts with receiving the online request from doctors and also allows laboratory personnel to generate requests. The Laboratory module supports to perform various tests under the following disciplines: Biochemistry, Cytology, Hematology, Microbiology, Serology, Neurology and Radiology. Tests are grouped under various sections and sample type (specimen). Based on the request the user can input the sample and generate the sample number. Results can be entered based on the sample type either to one test or multiple tests. If the test result requires approval, the supervisor has to approve the result and it is made available to concerned doctors. • • • • • • • •
Sample Result Entry Test Report Entry Antibiotic Details Result Range for Test Investigation Request Sample Details Samples Received from External Laboratory Samples Dispatch to External Reference Laboratory
Test report can be made confidential. Tests can be performed only after the billing is done. This rule is exempted when the case is declared as Urgent. In addition, this module facilitates investigations for referral patients. 3.1.9 Hospital Management System - User Manager The User Manager module basically deals with security through controlling the access to the information available in the application. Any user associated with a user group can access only those screens for which the user group has rights. It also deals with the System Related Activity like User Monitor, Creating User Group Master, User Master and view the User Group Lookup of employee database, Maintenance of company documents, User defined error message, Generating Daily Statistical Summary.
3.2 Database Design 3.2.1 Figure 3: Data Flow Diagram – typical hospital operations management systems
Patient In
1 Frontdesk Regis tr ation
query
Doctor Patient Info
Appointm ent
Visit
Lab report Patient
Prescription 2 Patient Vis it Schedule Test
Purchase Send Result
3 Lab Test
Check bil
Drug Store Bil Ok Bil in g
4 Adm is sion Check Bil Provide
BED
Bil OK OT Skdle
5 OT
Bed Rest
Check Bil
Dis charge check 6 Dis charge
Dis charge Certif ic ate
Patient Out
3.2.2 Figure 4: Entity Relationship Diagram – A typical hospital operations management system
Medicine
User
Bed
Radio/Image Test
Register
Provided
Schedule
Purchase
Patient
Schedule
Lab Test
Schedule
Supply
Supplier
Make
Payment
Visit
Operation
Make Appointment
Doctor
3.2.3 Relational Schema - A typical hospital operations management system USER (U_ID, U_NAME, U_GROUP, PASSWORD) PATIENT (PATIENT_ID, TITLE, NAME, ADDRESS, EMERGENCY_CONTACT, SEX, MARITAL_STATUS, BLOOD_GROUP, DOB, AGE, PAYMENT_TYPE, RELIGION, REF_BY, ENTRY_DATE, ENTRY_TIME, HISTORY, MEDICINE_ALERT, DIS_DATE, DIS_TIME, DIS_COMMENTS, ADVANCE, U_ID) BED (BED_ID, BED_TYPE, BED_DESC, BED_CHARGE) OPERATION (O_ID, O_DESC, O_CHARGE) DOCTOR (D_ID, D_NAME, D_CONTACT, D_QUALIFICATION) CONSULTANT (C_ID, C_NAME, C_CONTACT, C_QUALIFICATION, C_CHARGE) LAB (L_TEST_ID, L_NAME, L_CHARGE, L_TYPE)
RADIO_IMAGE (RI_TEST_ID, RI_NAME, RI_CHARGE, RI_TYPE) OTHER (OTHER_ID, OTHER_NAME, OTHER_CHARGE) BED_HISTORY (BED_ID, PATIENT_ID, MONEY_RECEIPT_NO, DATE, BED_CHARGE, NO_OF_DAY, BED_TOTAL, PAID) OPS_HISTORY (O_ID, PETIENT_ID, MONEY_RECEIPT_NO, DATE, O_CHARGE, PAID) DOCTOR_VISIT_HISTORY (D_ID, PETIENT_ID, VISIT_DATE, VISIT_TIME, PRESCRIPTION) CONSULTANT_HISTORY (C_ID, PETIENT_ID, MONYE_RECEIPT_NO, DATE, C_CHARGE, PAID) LAB_HISTORY (L_TEST_ID, PETIENT_ID, MONEY_RECEIPT_NO, DATE, L_CHARGE, DEL_DATE, PAID) RADIO_IMAGE_HISTORY (RI_TEST_ID, PETIENT_ID, MONYE_RECEIPT_NO, DATE, RI_CHARGE, DEL_DATE, PAID) PAYMENT (MONEY_RECEIPT_NO, P_AMOUNT, DISCOUNT, P_DATE, PETIENT_ID) APPOINTMENT (A_ID, A_DATE, SL_NO, VISITED, D_ID, PETIENT_ID) URINE_TEST (LAB_NO,...., PETIENT_ID) STOOL_TEST (LAB_NO,....., PETIENT_ID) BLOOD_TEST (LAB_NO,....., PETIENT_ID) MEDICINE (MEDICINE_ID, MEDICINE_NAME, MEDICINE_DESC, UNIT_ID, STOCK, RATE) MEDICINE_IN (MEDICINE_ID, SUPPLIER_ID, DATE_IN, UNIT_ID, UNIT, BATCH_NO, MFG_DATE, EXP_DATE) MEDICINE_OUT (PETIENT_ID, MEDICINE_ID, DATE_OUT, UNIT_ID, QUANTITY, RATE, AMOUNT, MONEY_RECEIPT_NO, PAID) SUPPLIER (SUPPLIER_ID, S_NAME, S_ADDRESS, S_TEL, S_FAX) UNIT (UNIT_ID, UNIT_DESC) 3.2.4 Data Dictionary Table 1. Data Dictionary of Entities SL Entity
Definitions
1 2 3
Patient User Lab Test
4
Radio/Image
5
Bed
6
Operation
7
Doctor
8 9 10 11
Medicine Supplier Payment Consultant
Patient comes hospital for treatment Employee of hospital There are different types of Laboratory Test performed in a hospital. Patient may use these services. There are different types of Radio/Image Test performed in a hospital. Patient may use these services. There are different types of Bed available in a hospital to be provided to Patient. There are different types of Operation performed in a hospital. Patient may use these services. Various specialist doctors work in a hospital. They visit patients. Medicines are available in drug store. Supplier of medicine Patient pay for the services Outside consultant also visit patients.
Table 2. Data Dictionary of Relationships SL 1
Relationships Bed_History
2
OPS_History
3
Doctor_visit_history
4
Consultant_History
5
Lab_History
6
Radio_Image_History
Definitions It represents relationship between Bed & Patient. A patient may occupy one or more bed. A bed may be provided to one or more patient. It represents relationship between Operation and Patient. A patient may schedule one or more Operation. A operation may be scheduled to one or more patient. It represents relationship between doctor visit & patient. A doctor may visit one or more patient. A patient may be visited by one or more doctor. It represents relationship between outside consultant & patient. A consultant may visit one or more patient. A patient may be visited by one or more consultant. It represents relationship between patient and Laboratory test. A patient may schedule one or more Laboratory Test and A Test may be scheduled to one or more patient. It represents relationship between
7 8 9
Medicine_In Medicine_Out Appointment
patient and Radiology & Imaging Test. A patient may schedule one or more Radio/Image Test and A Test may be scheduled to one or more patient. It represent stock in It represent stock out Patient makes appointment with doctor. A patient may make appointment with one or more doctor. A doctor may visit one or more out patient.
Table 3. Data Dictionary of Attributes SL 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
DATA ELEMENT U_ID U_NAME U_GROUP
DESCRIPTION Unique ID number of user Name of user Different user group are Administrator, Registration, Pharmacy, Lab, Accounts PASSWORD Password of user PATIENT ID A unique ID number of patient TITLE Salutation of patient such Mr., Mrs., Ms, Dr etc. NAME Name of patient ADDRESS Address of patient EMERGENCY_CONTACT Emergency contact telephone number of patient SEX Gender of patient either Male or Female MARITAL_STATUS Marital status of patient either Yes or No BLOOD_GROUP Blood group of patient DOB Date of Birth of patient AGE Age of patient PAYMENT_TYPE Type of payment whether its Self or sponsor REF_BY Patient is referenced by whom ENTRY_DATE Date of entry ENTRY_TIME Time of entry HISTORY Medical history of patient DIS_DATE Discharge date of patient DIS_TIME Discharge time of patient DIS_COMMENTS Discharge comments of patient ADVANCE Patient’s Advance money MEDICINE_ALERT Medicine alert of patient BED_ID ID number of Bed BED_TYPE Type of Bed BED_DESC Description of Bed BED_CHARGE Rate of particular Bed
DATA TYPE Characterr Character Character Character Character Character Character Character Character Character Logical Character Date Numeric Character Character Date Time Character Date Time Character Numeric Character Character Character Character Numeric
29 30 31 32 33 34 35
O_ID O_DESC O_CHARGE D_ID D_NAME D_QUALIFICATION D_CONTACT
36 37 38 39 40 41 42 43 44 45 46 47
C_ID C_NAME C_QUALIFICATION C_CHARGE C_CONTACT L_TEST_ID L_NAME L_CHARGE L_TYPE RI_TEST_ID RI_NAME RI_CHARGE
48 49 50 51 52 53
RI_TYPE OTHER_ID OTHER_NAME OTHER_CHARGE MONEY_RECEIPT_NO DATE
54 55 56
NO_OF_DAY BED_TOTAL PAID
57 58 59 60 61
VISIT_DATE VISIT_TIME PRESCRIPTION DEL_DATE P_AMOUNT
62 63 64 65 66 67
DISCOUNT P_DATE A_ID A_DATE SL_NO VISITED
68
MEDICINE_ID
69 70
MEDICINE_NAME UNIT_ID
ID number of Operation Description of Operation Charge of the particular operation ID number of doctor Name of doctor Qualification of doctor Contact telephone number of doctor ID number of consultant Name of consultant Qualification of consultant Charge of consultant Contact number of consultant ID number of LAB test LAB test name Charge of particular LAB test Category or type of LAB test. ID number of Radio/Image test Name of Radio/Image test Cost of particular Radio/Image test Type of Radio/Image test ID number of other services Name of other services Cost of particular other services Money receipt Serial No. Date of a particular service rendered. No of day(s) stayed at hospital Total Bed Charge Status of payment whether it is paid or not Doctor’s visit date Doctor’s visit time Doctor’s prescription Date of delivery for Lab test Amount paid by patient against a particular money receipt Discount on payment Date of payment Doctors Appointment ID Date of Appointment Serial Number of appointment A logical flag of visit. Whether doctors has visited patient or not. ID number of a particular medicine Name of medicine ID number of UNIT of medicine
Character Character Numeric Character Character Character Character Character Character Character Numeric Character Character Character Numeric Character Character Character Numeric Character Character Character Numeric Character Date Numeric Numeric Logical Date Time Character Date Numeric Numeric Date Character Date Numeric Logical Character Character Character
71
STOCK
72
RATE
73 74 75
MEDICINE_DESC SUPPLIER_ID UNIT
76 77
QUANTITY DATE_IN
78 79 80 81 82 83 84 85 86
DATE_OUT BATCH_NO MFG_DATE EXP_DATE S_NAME S_ADDRESS S_TEL S_FAX UNIT_DESC
Current stock of a particular medicine Selling Rate of a particular medicine Description of a medicine ID number of supplier Number of unit receive from supplier No of quantity sold to patient Date of medicine added in the stock Date of medicine out in the stock Batch No. of medicine Date of Manufactured Date of Expired Name of Supplier Address of Supplier Telephone nbr of supplier Fax nbr of supplier Description of Unit ID
Numeric Numeric Character Character Numeric Numeric Date Date Character Date Date Character Character Character Character Character
J2EE and .NET WEB SERVICES WEB SERVICES Our proposed system is based on 3-Tier Client-Server Architecture [we discussed detailed in Chapter 2]. In this architecture, the presentation, the application processing and the data management are logically separate processes. In our proposed systems we suggest to use .NET architecture with backend RDMBS Microsoft SQL Server. But alternate option J2EE can be used, we leave this choice to user. This is the era of distributing computing. Before designing any enterprise application, interoperability should be considered. There will be a time come, when a hospital require to communicate with various systems such as internal financial data, international health care organization, association of health care, potential customer etc. In that case we suggest to use Web Services. Web Services are module applications that adopting some language natural protocols, which can be published, located, and invoked through the Internet. One of the reasons that web service is a solution for system integration is the broad acceptance of this technology. Major vendors in the market including Microsoft, IBM, BEA, Sun Microsoft, Oracle‌. all agree with web service protocols and implement them in their products. Another major reason for adopting web services is the simplicity of these protocols. These XML based protocols are easy to use, and easy to attach on existing system that sometimes businesses don’t even need to change a line of code for the existing system.
Web Service is one of the most exciting technologies in today’s market, which is the most current tool for enabling distributed computing. In this section, we’ll introduce the history of the distributed computing, the concepts and protocols of web services, and the mainly applications for web services. 4.1
History of Distributed Computing Web Services are no more than agreements between different programmers while developing their applications, which is known as distributed computing. For two systems developing at the same time that both of the parties agree with some protocols for data exchanges, there is no pain to integrate them for developers. However, system developers usually can not expect what systems they will communicate with, nor they have the ability to decide the implementation for the other party. Another problem in today’s software market is that systems are usually developed in some vendor specified platforms, which means most fundamental infrastructures are already built while companies start to develop their own systems. The benefit of adopting a platform to develop the system is remarkable that programmers can focus on programming the business rules. However, it also draws the interpretable problems since vendors usually allow their platforms communicate with their own products, or even with the same operation systems. For example, the DCOM from Microsoft could not communicate with a system developed in the Java environment. Programmers were the losers in this kind of software battles between vendors. Each vendor has its own implementation on how to enable a distributed system, and programmers loose the ability to communicate with other systems or they need to write some application-specified programs for exchanging data in a case-by-case basis. The web services then emerged in a rapid pace after the major players in today’s market declare their supports on those web services related protocols, especially on the SOAP. While there are still some drawbacks in the web services model such as security issue, the low cost and simplicity have made a promise for a success for web services. Today, most vendors already have their implementations on web services that their platforms can talk with each other with only little effort. Before we dig into the web services protocols, we’ll review some of the important history that evolves this technology. DCOM The Microsoft developed Component Object Model (COM) in early 1990’s as a components development model for windows platform. Later on, it introduced the Distributed COM (DCOM) that crossed the machines boundaries. However, the DCOM is a Microsoft protocol that it only allows programs developed under windows platform to communicate. DCOM is very solid in security implementation but also very complicate. CORBA
The Common Object Request Broker Architecture (CORBA) was also introduced in early 1990’s as a cross-vendor initiative by the Object Management Group (OMG). The CORBA works in a stateful programming model that the program implement CORBA protocols need to maintain the status of the connection between the client and the server. Protocols of CORBA need to works with encapsulate binary code that makes the CORBA extremely complicate. RMI Sun Microsoft introduced the Remote Methods Invocation (RMI) in the Java class library that is embedded in the standard APIs. RMI played as proxies in between the two Java Virtual Machines and enable one of the JVM to use the resource in another machine like in it’s own JVM. The RMI crosses the boundaries of operation systems, but both sides need to be running JVM. XML-RPC It is fair to say that the SOAP is a descent of XML-RPC (XML Remote Procedure Call). The XML-RPC allows us to call procedures on remote machines without worrying about the operation system and language environment as long as they are connected with HTTP protocol. The main shortcoming of XML-RMI is that it lacks good data typing. For example, the XML-RPC does not handle advanced data structure even arrays well that most vendors did not fully embrace it. However, the experience of XML-RPC was used in the design of SOAP. EAI As SOAP, the Enterprise Application Integration (EAI) is an XML based protocol to connect applications. However, the EAI tends to be more specific to a particular business process, such as connecting a specific human resource application to a specific financial application. EAI was adopted by many applications but its implementation is more expensive and less flexible compare to the SOAP. 4.2
Introducing Web Services The web services contain three main blocks that are known as discovery, description, and invocation. As shown in the figure, to use a web service, a client program needs first to find the web service the services available. Next, the client needs to learn what the service does and what the service need from the description of the web service. Finally, the client consumes the web service by invoking the service and receives the result. Base on these main blocks, the Web Services architecture comprises the following components
Figure 5: The fundamental components of the Web services architecture The Service Provider The provider is generally responsible for providing the business logic and generating the description of the interface. From a business perspective, this is the owner of the service. From an architectural perspective, it is the platform that provides access to the service. The Service Requester The service requester is the service client that needs to request the service. The service requester is looking for a service through the broker and finally invoking the service of the service provider to acquire meaning information for it’s own business purposes. The Service Broker A Web Service Broker, or directory, plays the optional role of matchmaker in the enterprise Web services architecture. The broker function, while not strictly required, is widely assumed to be a critical component to facilitate dynamic discovery of desired Web services much like the yellow pages of today. While this is certainly a necessary function for building enterprise-class Web services that scale to support a large number of external, public partners, it is also a critical component when deploying web services within an enterprise or for use with private trading communities. In short, the broker is a searchable repository of service descriptions where service providers publish their Web Services descriptions and service requesters find and obtain binding information for Web Services. Web Service Protocols There are some important web service related protocols such as SOAP, WSDL, UDDI protocols, which are used to enable web services. Some other fundamental protocols such as HTTP, SMTP, FTP, XML are protocols other protocols build on. Other emerging protocols such as WSDL (from IBM) and XLANG (from Microsoft) are protocols for workflow global models that built on the web services.
Figure 6: Protocols used for web services workflow SOAP Based on the specifications from W3C, SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols. From a programming perspective, SOAP defines a messaging protocol between requestor and provider objects, such that the requesting objects can perform a remote method invocation on the providing objects in an object-oriented programming fashion. The SOAP specification was co-authored by Microsoft, IBM, Lotus, UserLand, and DevelopMentor. The beauty of SOAP is that it is completely vendor-neutral, allowing for independent implementations relative to platform, operating system, object model, and programming language. Additionally, transport and language bindings as well as data-encoding preferences are all implementation dependent. WSDL The Web Services Description Language is an XML vocabulary that provides a standard way of describing service IDLs. It provides a simple way for service providers to describe the format of requests and response messages for remote method invocations, or remote procedure call. In general, WSDL provides an abstract language for defining the published operations of a service with their respective parameters and data types. The language also addresses the definition of the location and binding details of the service. UDDI The Universal Description, Discovery, and Integration specification provides a common set of SOAP APIs that enable the implementation of a service broker. The UDDI specification was outlined by IBM, Microsoft, and Ariba to help facilitate the creation, description, discovery, and integration of Web based services. The
motivation behind UDDI.org, a partnership and cooperation between more than 70 industry and business leaders, is to define a standard for B2B interoperability. WSFL/ XLANG4 The Web Services Flow Language is an XML language for the description of Web Services compositions proposed by IBM. The attempt of WSFL is to treat web services as components and put them into applications. From the perspective of workflow, the WSFL combine all web services as activities the business process need, and route the process based on these activities to different roles to accomplish the process. WSFL considers two types of Web Services compositions: The first type specifies the appropriate usage pattern of a collection of Web Services, in such a way that the resulting composition describes how to achieve a particular business goal; typically, the result is a description of a business process. The second type specifies the interaction pattern of a collection of Web Services; in this case, the result is a description of the overall partner interactions The same idea of WSFL can be applied to the XLANG. XLANG is an early implementation provided by Microsoft for automation of business processes based on web services. This specification provides details about the message exchange behavior among participating web services. A workflow engine would have to be created to use XLANG or WSFL to actually track the state of process instances and help enforce protocol correctness in message flow. Both protocols can be implemented in any programming language and environment. 4.3
Applications of Web Services System Integration Web services are highly suited to integration since they offer a platform and technology-agnostic vehicle for creating interoperability between systems that were never designed to work together simply by adding a SOAP interface. Web services are easy to learn and they are backed by a rapidly evolving and broadly accepted set of industry standards. Usually, applications can locate web services using UDDI and determine the interface definition of the service using WSDL. In essence, Web services technology can be thought of as an evolution of function integration technology such as CORBA, as depicted in the following diagram:
Figure 7: Common Methods of Integrating Applications A major advantage of Web services over CORBA is that Web services technology is much less complicate. For example, web services do not require integration of an ORB (Object Request Broker), a task that is not for the faint of heart. Also because the underlying transport protocol behind Web services is based on XML over HTTP, it is fully compatible with firewalls and the Internet. With Web services, applications can be quickly and easily integrated into a portal or syndicated to a third-party business. However, as we can see from the figure, web services fall squarely in the function integration bucket. In order for Web services to be used for presentation layers integration, several extensions will needed to be made to the collection of Web services specifications. 4.4
J2EE and .NET J2EE and .NET are the most common choices in today’s market for enterprise application development. We’ll have some discussions on both of these technologies.
4.4.1 J2EE J2EE was the earliest platform designed for enterprise application development. The Sun Microsoft published the specifications for J2EE that vendors can implement them in their platforms, which are often called application servers. The only absence among big players is Microsoft, which uses the .NET framework. Other vendors like IBM (Web Sphere), BEA (Web Logic), Oracle (9i Application Server), SONY, HP, IONA… all stick with the J2EE technology.
Architecture Figure 8: J2EE Architecture Based on the blueprint from Sun Microsoft, The J2EE platform is designed to provide server-side and client-side support for developing distributed, multi-tier applications. Such applications are typically con-figured as a client tier to provide the user interface, one or more middle-tier modules that provide client services and business logic for an application, and back-end enterprise information systems providing data management. The above figure illustrates the various components and services that make up a typical J2EE environment. One of the most important components in the J2EE is the Enterprise Java Bean running in the EJB Container. We’ll discuss the EJB in the next session. A Web component in the web container is an entity that provides a response to a request. A Web component typically generates the user interface for an application. The J2EE platform specifies two types of Web components: servlets and JavaServer Pages. The EIS tier is the backbone for the J2EE application that connects to other systems or persistent data storage. EJB The Enterprise Java Beans architecture is a server-side technology for developing and deploying components containing the business logic of an enterprise application. Enterprise Java Beans components, also referred to as enterprise beans, are scalable, transactional, and multi-user secure. There are three types of enterprise beans: session beans, entity beans, and message-driven beans. Session and entity beans have two types of interfaces: a component interface and a home interface. The home interface defines methods to create, find, remove, and access metadata for the bean. The component interfaces define the bean’s business logic methods. Message-driven beans do not have component and home interfaces. An enterprise bean’s component and home interfaces are required to be either local or remote. Remote interfaces are RMI interfaces provided to allow the clients of a bean to be location independent. Regardless of whether the client of a bean that implements a remote interface is located on the same VM or a different VM, the client uses the
same API to access the bean’s methods. Arguments and return results are passed by value between a client and a remote enterprise bean, and thus there is a serialization overhead. A client of an enterprise bean that implements a local interface must be located in the same VM as the bean. Because object arguments and return results are passed by reference between a client and a local enterprise bean, there is no serialization overhead.
Figure 9: EJB Architecture .NET The .NET Framework is a new computing platform that simplifies application development in the highly distributed environment of the Internet. The .NET Framework has two main components: the common language runtime (CLR) and the .NET Framework class library. The CRL is the foundation of the .NET Framework that provides core services such as memory management, thread management, and remotely computing management. The class library is a comprehensive, object-oriented collection of reusable types that programmers can use to develop applications from command-line or windows applications to web applications based on the ASP.NET, such as Web Forms and web services. In the following, we’ll have an introduction to the ASP.NET and the new C# language, VB.NET. ASP.NET ASP.NET is more than the new version of Active Server Pages (ASP). It is Microsoft’s platform for developers to build enterprise-class web applications. While ASP.NET is largely syntax compatible with ASP, it also provides a new programming model and infrastructure to work with the .NET platform that programmers can develop the applications in any .NET compatible language such as Visual Basic .NET, C#, and Jscript .NET, and access the entire .NET Framework class libraries. This is illustrated in the figure below.
Figure 10: ASP.NET Architecture There are two different kinds of pages in ASP.NET, Web Forms and Web services. Web Forms are the new developing tools to generate forms-based Web pages. When building these pages, programmers use ASP.NET server controls to create common UI elements, and program them for common tasks. These controls release web developers from combining HTML codes with codes of other languages such as C#, VB.NET in a certain degree, and therefore, simply the developing process and increase the reusability of built-in or custom components. Web service provides the means to access server functionality remotely which contains the implementations for web services protocols such as SOAP and WSDL. The implementation in ASP.NET for web services is extremely easy that developer practically don’t need to understand all these protocols.
Figure 11: The Components of ASP.NET C# Language Microsoft C# is a new programming language that runs on the .NET Framework. Microsoft declares that C# is an evolution of Microsoft C and Microsoft C++ which is simple, modern, type safe, and object oriented. However, most programmers consider that C# is the strategy from Microsoft that help programmers to migrate to .NET from the Java platform.
Base on Microsoft, C# is a simple but powerful programming language intended for writing enterprise applications. The C# language uses many C++ features in the areas of statements, expressions, and operators. However, C# introduces considerable improvement and innovations in areas such as type safety, versioning, events, and garbage collection. The most powerful characteristic of C# is that it provides access to the common API styles which includes .NET Framework, COM, Automation, and C-style APIs. It also supports unsafe mode, which means programmers can use pointers to manipulate memory that is not under the control of the garbage collector. Visual Basic.Net Just as the computing landscape has transformed itself over the last decade, so too has Microsoft Visual Basic. For more than ten years, Visual Basic has fueled the growth of client/server applications, 32-bit programming, and component development. It is the backbone of thousands if not millions of critical business systems throughout the world. Now, as the computing industry looks to address a new set of challenges focusing on Internet, mobile, and Web service development, a new version of Visual Basic—Visual Basic .NET—is once again at the forefront of technology, ready to fuel the growth of the next generation of application development. Like Visual Basic 1, Visual Basic .NET is both evolutionary and revolutionary. It builds on the key strengths of previous versions of Visual Basic and extends rapid application development to the server and to the Web with XML Web services, Web Forms, trickle-down deployment of Windows applications, and the ability to write Windows services. Visual Basic .NET also delivers some of the most asked-for features: real inheritance and the ability to cleanly implement object-oriented designs, better integration with other languages, seamless deployment, and versioning. Conclusion: Working on this Hospital Management Systems project has exposed our project group to a variety of technologies and taught us many lessons that have applicability far beyond the process of simply making hospital management systems. From a technology viewpoint, we have discussed the most current J2EE and .NET framework as well as Web Services technology. The structured approach to information systems development has been found to be still most popular among the information systems and database developers. The methodology thus determined has then been followed to design a relational database for a typical hospital. The design thus produced can be implemented in most popular Relational Database Microsoft SQL Server. The success of an information system in an organization lies in its use by the decision makers in the desired manner. A system may be developed using a highly sophisticated methodology. But if it becomes a right system for the wrong persons, there lies the high possibility that the system will not be used in the desired manner. In Bangladesh, most of the hospitals don’t have comprehensive IS/IT facility. Effective use of IS within an organization depend on many things, among them senior
management leadership and commitment, the skills of IS staff and management, the selection and use of technologies and the planning and implementation process, etc. So, it is imperative to have MIS setups for effective use of Information Systems.