EARLIEST PRIORITY DATE:

This Application claims priority from a Provisional patent application filed in India having Patent Application No. 202131029002 filed on August 29, 2021 and titled “SYSTEM AND METHOD FOR END-TO-END HOSPITAL MANAGEMENT”

FIELD OF INVENTION

Embodiments of the present disclosure relate to management of healthcare, and more particularly to a system and method for end-to-end hospital management.

BACKGROUND

The Golden Hour (more scientifically referred to as the "resuscitative hour") is first 60 minutes following any injury or trauma. Quick medical care during this period can save one’s life. Golden one hour and Platinum 10 minutes are the critical time window as chances of survival depend on this window period.

In much of the world, road traffic accident victims and others suffering life-threatening injuries are unable to get essential surgical care within an hour following an accident. People suffering from Combined Stroke, CHF (Congestive Heart Failure) and Myocardial Infarctions (MI) are also a major victim of death and disabilities due to lack of medical attention within one hour.

The window of opportunity for a chance at survival is narrow for a severely injured patient. Road traffic and other injuries kill more people every year than Human Immunodeficiency Virus caused Acquired Immunodeficiency Syndrome (HIV- AIDS), tuberculosis, and malaria combined. Though injury -related deaths occur everywhere, the overwhelming majority happen in low- and middle-income countries (LMICs), where emergency communication systems and health care are often limited. Specialized and timely trauma care in Low and Middle Income Countries (LMICs) is critical, though, to reducing permanent, long-term disability and deaths.

Hospitals are crucial part of everyone’s lives. Management of every part and department in hospital is important. Everyday many people enter and exit the hospital. Keeping a record of all individuals gets difficult. Sometimes, man-made mistakes can become troublesome with patient’s care. Due to COVID times, admitting, booking an appointment, booking a test, maintaining the no of beds occupied and are remaining, keeping all the records of the tests taken should be done at a faster pace. Making sure other parts of the hospital does not face any difficulties is essential. Having a good management system for the hospital can reduce a lot of problems.

Existing solution to the aforementioned issues is a management system which is computerized to some extent. It solves complication from managing all paperwork of every patient with confidentiality. The registration, bed allocation, planning of resources for surgeries and the like is done by hospital officials. It provides facilities like maintaining the medical record of the patient, maintaining the contact details of the patient, saving the insurance information for later use, keeping track of the payments and the like.

Existing solution differ at large in providing optimum care to the patient due to lack of data synchronization, a global gap between doctors to patient ratio and doctors to nurse ratio. It lacks in transparency. Due to recent times a complete e-software is necessary. There is dependency of hardcopy.

Hence, there is a need for a system and method for end-to-end hospital management using a hospital management system.

SUMMARY

In accordance with one embodiment of the disclosure, a system for managing healthcare data and end-to-end hospital management using a hospital management system is provided. The system includes a hardware processor and a memory. The memory is coupled to the hardware processor and the memory includes a set of program instructions in the form of a plurality of subsystems configured to be executed by the hardware processor. The plurality of subsystems includes a patient registration subsystem, a doctor specific patient dashboard subsystem, a nursing management subsystem, a pharmacy distribution management subsystem, a laboratory information subsystem, and a medical treatment cost assessor subsystem.

The patient registration subsystem obtains information related to a patient upon registration by the patient. The information related to the patient includes at least one of vital tests of the patient, demographic information of the patient comprising a name, an address, a gender of the patient, and previous medical history of the patient. The doctor specific patient dashboard subsystem obtains the information related to the patient from the patient registration subsystem and transmits the information related to the patient to a specific healthcare provider based on historical data of the patient retrieved from a healthcare management database. The doctor specific patient dashboard subsystem allows the healthcare provider to provide digitized prescription, digitized bed notes, e-prescription to the patient based on the information related to the patient. Further, the specific healthcare provider is authenticated with details comprising a list of tenants, hospitals, and corresponding data comprising email id, mobile number, and role-id.

The nursing management subsystem obtains regular turnaround time (TAT) alerts for every patient with patient identification (ID) or name, bed number, and room number based on the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider to perform activities comprising time to time medication, checking vitals, and recording readings from display monitors. The pharmacy distribution management subsystem obtains inputs from the nursing management subsystem and analyses the inputs to distribute medicines to the patient. The pharmacy distribution management subsystem compares the input comprising the data related to the digitized prescription, the digitized bed notes, and the e- prescription provided by the healthcare provider with data related to medicines and equipment stored in a pharmacy.

The laboratory information subsystem receives orders from the healthcare provider and to allow a user to generate requests to process results based on data related to a sample received from the patient. The medical treatment cost assessor subsystem estimates cost for medical treatments comprising procedure and day care treatments and longer stay treatments provided to the patient using a deep machine learning algorithm by (a) obtaining charges table for different basic procedures and day care medical treatment facilities, (b) analysing diagnosis and disease wise day stay with list of services to be offered to the patient, (c) performing analysis and comparison-based learning from services provided for identical diseases and diagnosis, and (d) assessing insurance cost based on learning and the medical treatments offered to the patient.

In one aspect, a method for managing healthcare data and end-to-end hospital management using a hospital management system. The method includes following steps of: (a) obtaining, using a patient registration subsystem, information related to a patient upon registration by the patient; (b) obtaining, using a doctor specific patient dashboard subsystem, the information related to the patient from the patient registration subsystem; (c) transmitting, using the doctor specific patient dashboard subsystem, the information related to the patient to a specific healthcare provider based on historical data of the patient retrieved from a healthcare management database; (d) obtaining, using a nursing management subsystem, regular turnaround time (TAT) alerts for every patient with patient identification (ID) or name, bed number, and room number based on the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider to perform activities comprising time to time medication, checking vitals, and recording readings from display monitors; (e) obtaining, using a pharmacy distribution management subsystem, inputs from the nursing management subsystem and analyses the inputs to distribute medicines to the patient; (f) comparing, using the pharmacy distribution management subsystem, the input comprising the data related to the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider with data related to medicines and equipment stored in a pharmacy; (g) receiving, using a laboratory information subsystem, orders from the healthcare provider and to allow a user to generate requests to process results based on data related to a sample received from the patient; and (h) estimating, using a medical treatment cost assessor subsystem, cost for medical treatments comprising procedure and day care treatments and longer stay treatments provided to the patient using a deep machine learning algorithm.

In an embodiment, estimating the cost for medical treatments using the deep machine learning algorithm comprises obtaining charges table for different basic procedures and day care medical treatment facilities; analysing diagnosis and disease wise day stay with list of services to be offered to the patient; performing analysis and comparison-based learning from services provided for identical diseases and diagnosis; and assessing insurance cost based on learning and the medical treatments offered to the patient.

To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will follow by reference to specific embodiments thereof, which are illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting in scope. The disclosure will be described and explained with additional specificity and detail with the appended figures.

BRIEF DESCRIPTION OF DRAWINGS The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:

FIG. 1 is a block diagram of a system for managing healthcare data and end-to-end hospital management using a hospital management system, in accordance with an embodiment of present disclosure;

FIG. 2 is a block diagram illustrating an exemplary hospital management system, such as those shown in FIG. 1, in accordance with an embodiment of the present disclosure;

FIG. 3 is a functional view of a system architecture for managing hospital, in accordance with an embodiment of the present disclosure;

FIG. 4 is a software view of the system architecture of the hospital management system for managing hospital, in accordance with an embodiment of the present disclosure;

FIG. 5 is a process flow of a patient registration subsystem for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 6 is a process flow for a doctor specific patient dashboard subsystem for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 7 is a process flow chart of an admission, transfer, and discharge subsystem for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 8 is a process flow for an instant admission process of the patient through the patient’s personal device 104 using the admission, transfer, and discharge subsystem 216, in accordance with an embodiment of the present disclosure;

FIG. 9 is a process flow for an instant discharge process of the patient through the mobile application using the admission, transfer, and discharge subsystem 216, in accordance with an embodiment of the present disclosure;

FIG. 10 is an exemplary view of a nursing management subsystem for creating automated nursing roster, in accordance with an embodiment of the present disclosure; FIG. 11 is an exemplary view of the nursing management subsystem for creating a nursing dashboard for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 12 is a process flow diagram of a pharmacy distribution management subsystem for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 13 is a process flow diagram of a laboratory information subsystem for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 14 is a process flow for an inventory management subsystem for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 15 is a reference model diagram in estimating a cost for medical treatments using a medical treatment cost assessor subsystem with a deep machine learning algorithm, in accordance with an embodiment of the present disclosure;

FIG. 16 is a reference model diagram in decision making for management of hospital, in accordance with an embodiment of the present disclosure;

FIG. 17 is a block diagram of a clinical decision support subsystem (CDSS) integration module for management of hospital, in accordance with an embodiment of the present disclosure; and

FIG. 18 is a computer implemented method for managing healthcare data and end-to-end hospital management using a hospital management system, in accordance with an embodiment of present disclosure.

Further, those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.

DETAILED DESCRIPTION For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood, that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated online platform, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.

The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or subsystems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, subsystems, elements, structures, components, additional devices, additional subsystems, additional elements, additional structures, or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.

In the following specification and the claims, reference will be made to a number of terms, which shall be defined to have the following meanings. The singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise.

FIG. 1 is a block diagram of a system 100 for managing healthcare data and end-to-end hospital management using a hospital management system 106, in accordance with an embodiment of present disclosure. The system 100 manages the healthcare data and end-to-end-hospital management using the hospital management system 106. The hospital management system 106 obtains information related to a patient 102 upon registration by the patient 102 via a patient’s personal device 104. The information related to the patient 102 includes at least one of vital tests of the patient 102, demographic information of the patient 102 comprising a name, an address, a gender of the patient 102, a previous medical history of the patient 102, and the like. The system 100, using a plurality of subsystems 108 included in the hospital management system 106, helps the users 110 in different departments (e.g., a doctor, a nurse, a caretaker, a person in pharmacy, a person in laboratory, and the like) to manage the patients 102 through a user device or user’s mobile device 112 according to a severity of the patient’s health. In an embodiment, the hospital management system 106 is a could based management system.

FIG. 2 is a block diagram illustrating an exemplary hospital management system 104, such as those shown in FIG. 1, in accordance with an embodiment of the present disclosure. The hospital management system 106 includes a hardware processor 234. The hospital management system 106 also includes a memory 202 coupled to the hardware processor 234. The memory 202 includes a set of program instructions in the form of the plurality of subsystems 108.

The hardware processor(s) 234, as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing microprocessor, a reduced instruction set computing microprocessor, a very long instruction word microprocessor, an explicitly parallel instruction computing microprocessor, a digital signal processor, or any other type of processing circuit, or a combination thereof.

The memory 202 includes the plurality of subsystems 108 stored in the form of executable program which instructs the hardware processor 234 via a system bus 230 to perform the above- mentioned method steps. The plurality of subsystems 108 include following subsystems: a patient registration subsystem 204, a doctor specific patient dashboard subsystem 206, a nursing management subsystem 208, a pharmacy distribution management subsystem 210, a laboratory information subsystem 212, a medical treatment cost assessor subsystem 214, an admission, transfer, and discharge subsystem 216, a ward management subsystem 218, a radiology and medical information subsystem 220, an inventory management subsystem 222, a clinical decision support subsystem 224, a human resource management subsystem 226, and a reporting subsystem 228.

Computer memory elements may include any suitable memory device(s) for storing data and executable program, such as read only memory, random access memory, erasable programmable read only memory, electrically erasable programmable read only memory, hard drive, removable media drive for handling memory cards and the like. Embodiments of the present subject matter may be implemented in conjunction with program modules, including functions, procedures, data structures, and application programs, for performing tasks, or defining abstract data types or low-level hardware contexts. Executable program stored on any of the above-mentioned storage media may be executable by the hardware processor(s) 234.

The hospital management system 106 includes the patient registration subsystem 204 that is communicatively connected to the hardware processor 234. The patient registration subsystem 204 obtains information related to a patient 102 upon registration by the patient 102. The information related to the patient 102 comprises at least one of vital tests of the patient 102, demographic information of the patient 102 including a name, an address, a gender of the patient 102, a previous medical history of the patient 102, and the like. In an embodiment, the patient 102 registers the information through the patient’s personal device 104. In another embodiment, the registration of the patient 102 is inputted by a third person (e.g., relatives of the patient 102). In an embodiment, the patient’s personal device 104 includes at least one of: a mobile phone, a smart phone, a laptop, a personal computer, a personal digital assistant (PDA), an electronic notebook, and the like.

The hospital management system 106 includes the doctor specific patient dashboard subsystem 206 that is communicatively connected to the hardware processor 234. The doctor specific patient dashboard subsystem 206 obtains information related to the patient 102 from the patient registration subsystem 204 and to transmit the information to a specific healthcare provider 110 based on historical data of the patient 102 retrieved from a healthcare management database. The doctor specific patient dashboard subsystem 206 allows the healthcare provider 110 to provide digitized prescription, digitized bed notes, e-prescription to the patient based on the information related to the patient 102. In an embodiment, the specific healthcare provider 110 is authenticated with details comprising a list of tenants, hospitals, and corresponding data comprising email id, mobile number, and role-id. In another embodiment, the specific healthcare provider 110 is at least one of: a doctor 110, a nurse, a caretaker of the patient 102, and the like.

The hospital management system 106 includes the nursing management subsystem 208 that is communicatively connected to the hardware processor 234. The nursing management subsystem 208 enables the user (e.g., the nurse or the ward staff) to facilitate and manage their wards on a floor. The nursing management subsystem 208 obtains regular turnaround time (TAT) alerts for every patient 102 with patient identification (ID) or name, bed number, and room number based on the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider 110 to perform various activities including time to time medication, checking vitals, and recording readings from display monitors. In an embodiment, the nursing management subsystem 208 allows the user to monitor medical services provided to the patient 102 in an intensive care unit (ICU) and an operation theatre (OT) in a respective ward that is assigned to the user.

The nursing management subsystem 208 includes functions such as access to patient administration system, ability to link in with the order communications, notification of patient’ s 102 pending arrival, current status, and the like. The nursing management subsystem 208 further includes comprehensive charts to monitor the patient’s 102 condition, real time test, procedure, and medication ordering to the concerned departments. For surgery, the theatre schedule is notified together with any preparation required. The nursing management subsystem 208 has ability to record admissions, discharge, and transfers at the wards to update the bed census. The nursing management subsystem 208 confirms location of the patient 102 and notifies the location to ancillary departments such as dietary, and the like. The nursing management subsystem 208 further communicates with departments such as housekeeping, maintenance, security, and the like to monitor them to make the hospital clean. The nursing management subsystem 208 includes nursing Kardex in paediatric Intensive Care Unit (PICU) and neonatal intensive care unit (NICU). The nursing management subsystem 208 includes procedure notes and nursing notes for future use.

The nursing management subsystem 208 provides more benefits to nurses. The nurses get regular turnaround time (TAT) alerts for every patient identification (ID), or name or bed number Room number based on doctors digitized prescription, digitized bed notes, e- prescription for administering time to time medication, checking vitals, recording readings from monitors and the like. If the turnaround time (TAT) is missed, the matter would be escalated to the floor in charge and nursing in charge and must be addressed. Nurses, from their personal device, can update patient's 102 vitals and turnaround time (TAT) closure indication. It is ideally against biometrics matching of patient 102 & nurse. In database, detail gets stored on what time who checked vitals and administered what medicines and the like. If nurse sees that the patient 102 is not responding or some monitor alert appears he or she can immediately report the same incident via emergency bottom in the personal device which gets a code blue team assigned by hospital clinical board along with the concerned doctor 110, resident medical officer (RMO) and emergency doctor. If patient 102 or patient party places a request or an order such as food and beverages (F&B), housekeeping, change of linen, dress, floor cleaning, adjust air condition (AC) temperature, and the like to nurse, through the tablet itself the Nurse can place that order against patient's identification (ID) and health-e 360 assigns turnaround time (TAT) to respective department and personnel assigned as per escalation hierarchy. The nurses need not waste time standing in que to take clinical file or bed notes to doctors 110, as they can directly send updated digital file to doctors 110 and take their e-prescription or opinion instantly.

In case of any clinical negligence event, the nursing management subsystem 208 shows clearly if it was the nurse's negligence or not. If yes, then the nursing management subsystem 208 points out who and which incidents caused the act of negligence. To prepare a discharge summary for hospital, a health statement along with time, prescription, reports are generated just in one click. The doctor 110 can review before taking a printout and handing over the same to respective patient 102. Nurse can directly book or scheduled investigation or sample collection or imaging and other services on priority basis if its needed. The process can also be automated based on bed notes of respective patients 102.

The hospital management system 106 further includes the pharmacy distribution management subsystem 210 that is communicatively connected to the hardware processor 234. The pharmacy distribution management subsystem 210 obtain inputs from the nursing management subsystem 208 and analyses the inputs to distribute medicines to the patient 102. The pharmacy distribution management subsystem 210 compares the input that includes the data related to the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider 110 with data related to medicines and equipment stored in a pharmacy.

The hospital management system 106 includes the laboratory information subsystem 212 that is communicatively connected to the hardware processor 234. The laboratory information subsystem 212 receives orders from the healthcare provider 110 and to allow a user of the laboratory to generate requests to process results based on data related to a sample received from the patient 102.

The hospital management system 106 further includes the medical treatment cost assessor subsystem 214 that is communicatively connected to the hardware processor 234. The medical treatment cost assessor subsystem 214 estimates cost for medical treatments including procedure and day care treatments and longer stay treatments provided to the patient 102 using a deep machine learning algorithm. The deep machine learning algorithm in the medical treatment cost assessor subsystem 214 helps to estimate the cost for the medical treatments by (a) obtaining charges table for different basic procedures and day care medical treatment facilities, (b) analysing diagnosis and disease wise day stay with list of services to be offered to the patient 102, performing analysis and comparison-based learning from services provided for identical diseases and diagnosis, and assessing insurance cost based on learning and the medical treatments offered to the patient 102.

The hospital management system 106 further includes the admission, transfer, and discharge subsystem 216 that is communicatively connected to the hardware processor 234. The admission, transfer, and discharge subsystem 216 enables a user of the patient 102 to search on availability and to manage information of an allocation of a bed, a ward and a room to the patient 102 according to the availability and cost associated based on a severity of the patient 102. The admission, transfer, and discharge subsystem 216 further sends the information to the healthcare provider 110 to provide at least one of: the medical treatment, surgery or medical diagnosis based on the severity of the patient 102. The admission, transfer, and discharge subsystem 216 further uses a comprehensive form to collect precise data regarding the patient 102, thorough evaluation of the patient condition, recording healthcare provider’s 110 notes for further management, processing orders in real time to respective departments, managing billing process, managing payments done by patient’s relatives, bed and ward allocation and transfer, e-prescription of medications to analyse a current status of the patient 102 for discharge. The admission, transfer, and discharge subsystem 216 generates a discharge summary with an appropriate discharge procedure based on the analysis of the current status of the patient 102.

The hospital management system 106 further includes the ward management subsystem 218 that is communicatively connected to the hardware processor 234. The ward management subsystem 218 is integrated solutions for all nursing stations in the wards, surgical intensive care unit (ICU), medical care unit and day-care. The ward management subsystem 218 allow the user to perform nursing procedures, clinical procedures, in-patient service allocation, pharmacy order, and lab and blood bank services. In an embodiment, the nursing procedures include activities, that are allocated to the specific patient 102 by the healthcare provider 110, are viewed and rendered using the ward management subsystem 218. In an embodiment, the activities include searching and selection of the patient 102, monitoring of patient health status, material requisition for patient’s medical consumable needs to central stores, roster management bed transfer, and the like. In an embodiment, the user may be an expert in the particular medical departments. For example, the user may be a nurse expertise in monitoring patients 102 in ICU, a caretaker expertise in monitoring patients 102 in general ward, a person expertise in laboratory department, a person expertise in pharmacy, a person expertise in radiology department, and the like.

The hospital management system 106 further includes the radiology and medical information subsystem 220 that is communicatively connected to the hardware processor 234. The radiology and medical information subsystem 220 manage radiology services and equipment corresponding to the medical treatment. In an embodiment, the radiology and medical information subsystem 220 stores images, scans, and electrocardiography (ECG) graphs related to the patient 102 in the system or to store as electronic files with picture archive and communication system (PACS) to eliminate unnecessary retrieval and dissemination of films.

The radiology and medical information subsystem 220 facilitates management of the workflow of radiology services and equipment, in addition to supporting entry of work records and reports. The ultimate objective is to store all patient images, scans, and electrocardiography (ECG) graphs in the system or as electronic files due to its integration with picture archive and communication system (PACS), thereby eliminating the unnecessary retrieval and dissemination of films. In an embodiment, only eligible people with authorized access are allowed to access the radiology and medical information subsystem 220, thereby maintaining the confidentiality of patients’ 102 films. The radiology or medical information subsystem 220 includes features such as service and test setup, sponsor- wise service is mapped with diagnostic tests, billing using lab orders from clinical module, requisition generation from lab order or bill requisition, creation based on facility, test, and modality, message generation for patient creation, order creation, requisition status change, report entry using templates, reporting with Hl 10, message generation and send it to picture archive and communication system (PACS), results authorization, redo process, status update, prints with national accreditation board for testing and calibration laboratories (NABL) standards, print queue process, access previous lab results based on tests and unique hospital identification number (UHID) number, dashboard for authorization, dashboard for tat, dashboard for work in progress, and the like.

The hospital management system 106 further includes the inventory management subsystem 222 that is communicatively connected to the hardware processor 234. The inventory management subsystem 222 receives requests from different subsystems corresponding to different departments in the hospital for purchasing items related to the medical treatment upon analyzing that the items related to the medical treatment are deficit.

The hospital management system 106 further includes the clinical decision support subsystem (CDSS) 224 that is communicatively connected to the hardware processor 234. The clinical decision support system 224 helps the management and the hospital to make right decisions. In an embodiment, the clinical decision support system 224 is an add-on part in the hospital management system (HMS) 106. The clinical decision support system 224 includes various chief characteristics including new data accumulation. The new data accumulation consists of patient’s previous medical records, collected vitals and symptoms contribute to decisions for diagnostic test ordering. In an embodiment, test results form the basis for patient diagnosis. The diagnosis, in turn, is decisive for a choice of an optimal treatment. In an embodiment, the characteristic of the clinical decision support system 224 is data repetition and loop of diagnosis practice. This characteristic includes the result of a diagnostic test that might direct physicians to go for additional tests, as a requirement for successful differential diagnosis. In addition, a diagnostic test may be repeated, during a periodic assessment, to confirm or alter the therapeutic schema in response to the updated diagnostic test results. These feedback loops and repeated measurements are often mandated as requirements of hospital clinical pathways and protocols of care. Another characteristic of the clinical decision support system 224 is combining different kinds of clinical data for decision making. This characteristic consists of a variety of different data that needs to be combined in decision making. For example, combining diagnostic test results with patient history, physical examination, and symptoms, to form the diagnosis or the combination of lab test results, the diagnosis, patient history, physical examination, and treatment to predict the patient prognosis.

Another characteristic of the clinical decision support system 224 is reusing the same data in multiple decisions. This characteristic includes in clinical practice. The data facilitates more than one decision. Data is generated to support a specific decision-making process, that can be reused later for another decision. For example, while lab and radiology results are primarily ordered to set a diagnosis, they are later utilized for treatment decisions, or for the patient prognosis. Another characteristic of the clinical decision support system 224 is human cognitive skills and knowledge to process the information. This characteristic includes in clinical decisions, clinical data are assessed by physician’s knowledge and decision-making skills. The hospital management system 106 further includes the human resource management subsystem 226 that is communicatively connected to the hardware processor 234. The human resource management subsystem 226 takes care of the complete working of the human resources management in the hospital from the time candidates apply for a job till the time they resign. The human resource management subsystem 226 includes a variety of activities including deciding what staffing needs you have, recruiting, training, and conforming to various regulations, maintaining shift rotation, and delivering reports on workload on an individual. The human resource management subsystem 226 includes various features such as interface with biometrics for daily attendance, leave management, duty roster, overtime management, salary, provident fund (PF), tax deducted at source (TDS), loans management, pay slip generation through intranet portal, bonus, and incentive management, outsource employee management, and the like.

The hospital management system 106 further includes the reporting subsystem 228 that is communicatively connected to the hardware processor 234. The reporting subsystem 228 provides information to management on the way to help them taking the right decisions. The reporting subsystem 228 helps in measuring the performance of each department in the hospital. In an embodiment, data can be mined as per analysis required. The reporting subsystem 228 includes features such as privilege dashboards for the department heads to monitor and measure performance, top management dashboards, clinical dashboards, facility for exporting the data into various formats like Excel and portable document format (PDF), department-wise revenue details, quality indicators as per national accreditation board for hospitals and healthcare providers (NABH) and joint commission international (JCI) requirements, easily customizable reports as per the management’s needs, auto- scheduler for generating the reports and sending the reports by email, short message service (SMS) alerts generation, operational business reporting for work reports, page perfect reports for formatted documents such as delivery notes, accounting documents, and the like. The reporting subsystem 228 also includes pixel perfect reports for documents such as control panel or data analysis.

FIG. 3 is a functional view of a system architecture 300 for managing hospital, in accordance with an embodiment of the present disclosure. The system architecture 300 includes cloud service provider such as azure and amazon web services (AWS) 302. The system architecture 300 further includes a hospital cloud-service consumer option (i.e., a software as a service (SaaS) tenant) 304 that includes tools to integrate cloud services 308 and an in-house support team 308. The system architecture 300 further includes a cloud service creator 310 including tools to create service 312. The system architecture 300 includes various cloud services including a business process as a service (BPaaS) 314 and healthcare software as a service (SaaS) including patient management, appointment booking, pharmacy, labs and radiology, and various other subsystems, and the like.

The system architecture 300 includes a common cloud management platform 316 that includes a service provider portal and an application programming interface (API), a service consumer portal and a corresponding application programming interface (API) 318, a service developer portal and a corresponding application programming interface (API), and the like. The common cloud management platform 316 further includes an operational support service (OSS) 320 that includes provisioning, configuring, monitoring, logging, service management and administration. The common cloud management platform 316 further includes a business support service (BSS) 322 that includes tenant and user management, authentication and authorization, security, billing and metering, report and analytics, customization, contact and agreement, and the like. The system architecture 300 further includes technical services 324 including cross platform user interface (UI) framework, security, base framework, and service- oriented architecture (SOA) framework. The system architecture 300 further includes data services 326 including multi-tenant, hospital catalog, healthcare and a IPurna web application. The system architecture 300 further includes a platform as a service (PaaS) 328 that includes platform and framework, management, and a software development kit (SDK). Additionally, the system architecture 300 includes information as a service (laaS) 330 that includes virtualization, server, networking, storage, and the like.

FIG. 4 is a software view of a system architecture 400 of a hospital management system 106 for managing hospital, in accordance with an embodiment of the present disclosure. The system architecture 400 is a software as a service (SaaS) compatible application consisting of multiple subsystems. The system architecture 400 includes an HMS client 402 (e.g., Edge, Chrome, Safari, Firefox, Windows, Android, iOS, and the like), an external system 404 with an application programming interface (API), a HMS cloud 406, an operating management 408, a development platform 414 and a visual studio platform 416. The HMS cloud 406 includes (a) a presentation layer 410 including components of HTML 5, CSS3, Javascript, Jqery, Angular, Data Modelling Engine, UI framework and components, (b) a business process layer including .NET, C# Web API core 3.1, Windows workflow foundation, (c) a service layer including HMS business hosting service, (d) a data layer including an entity framework and data helper, (e) data sources including a SQL server, (f) .NET framework 4.5 later, and (g) Windows server 2012 later/Linux distros. The HMS cloud 406 further includes the web application programming interface (API) 412 that is developed in C#. Net Core 3.1 and user interface (UI) is developed with angular 10 abiding security protocol using Rivest, Shamir, Adleman (RSA) token, AES256, Anti forgery mechanism, authorization access filter, token-based authentication using json web token (JWT) token (Hanc SHA 256 algorithm). Further, the development platform 414 includes at least one of: (a) Angular 10 and Angular Cu, (b) .NET, C# Web API core 3.1, (c) JWT authentication, (d) Entity Framework CodeFirst, (e) a SQL server, and the like.

The system architecture 400 is integrated with other web applications like iPuma.com and mobile applications such as iPurna. In an embodiment, the mobile application is available on apple application store and google play store. The mobile application follows software as a service (SaaS) compatible architecture. The system architecture 400 is an amazon web services (AWS) compatible architecture. The application programming interface (API) is exposed by the system architecture 400, which is consumed by the web application and the mobile application. In an embodiment, the system architecture 400 meets objectives including a system supporting multi-tenant software as a service (SaaS). This system architecture 400 provides fast performance.

FIG. 5 consists of a process flow 500 of the patient registration subsystem 204 for management of hospital, in accordance with an embodiment of the present disclosure. In one embodiment, the patient registration subsystem 204 includes patient details based on general and demographic information. A unique health identification number (UHID) is allocated to patients 102 at the time of registration 502. This UHID includes detailed information of the patients 102. In an embodiment, all the crucial patient information as per joint commission international (JCI) standards is mentioned as mandatory fields. Alerts are present in place to prevent erroneous data entry. A smart card is generated with the unique health identification number (UHID). In an embodiment, there are advanced multi -criteria search for registered patients 102. There is a provision for recording sponsor, insurance, and medical tourism details. This provision is integrated with the mobile application and website application. Another embodiment of the present disclosure provides an outpatient management subsystem, which deals with basic medical treatment details. The outpatient management subsystem enables the patient 102 to register at the reception as shown in step 502. The outpatient management subsystem then determines whether the patient is in critical condition as shown in step 504. If yes, the patient 102 is taken to an emergency with the help of an attendant, as shown in step 506. If no, the outpatient management subsystem helps the patient 102 for appointment with a specific doctor 110. If the doctor is available, then the outpatient management subsystem schedules for appointment in 510. If not, it checks for the selected doctor’s 110 availability. If the appointment is fixed, the outpatient management subsystem looks for next appointment or revisit to the doctor 110 in 516. Further, the outpatient management subsystem enables the patient 102 to collect the registration form in 518. The outpatient management subsystem further arranges for the doctor consultation in 528 and enables the patient 102 to get digital prescription from the doctor 110 in 540 upon the submitting the filled form in 520, and payment done by the patient 102 in 522. The outpatient management subsystem enables the doctor 110 to help the patient in referring the other specialist in 530 based on the health condition of the patient 102. In an embodiment, the doctor’s consultation includes further processes such as necessity of emergency admission as in 532, IPD admission formalities in 534 upon necessity of the emergency admission, counselling for lab/pharmacy in 536 when the emergency admission is not required, and lab/pharmacy billing in 538 for lab/pharmacy processes. Ina n embodiment, reports including the information related to the lab/pharmacy, consultation of the diction 110, and the like are uploaded in the system 100 available in the mobile application of the patient 102. Further, the doctor 110 provides digital prescription, which is received by the patient 102 as an alert on medicine intake, refill, order, and diagnosis based advice as in step 540.

In an embodiment, the outpatient management subsystem is dependent on other subsystems for acquiring registration details, book appointments for consultations, test appointment, report viewing, and the like. The outpatient management subsystem includes features including dashboards for patient’s activity or sponsor activity, dashboards for user activity, dashboard for advances or payments or refunds. The outpatient subsystem performs unique hospital identification number (UHID) creation, merging, activation. The outpatient management subsystem includes all the schedules for doctors. The outpatient management subsystem also includes patient evaluation diagnosis. For example, the patient 102 schedules a follow-up appointment with the doctor 110 and opt for a second opinion based on the digital files. E-consultation is done based on fresh diagnostics reports. There is time to time medicine intake reminder as per digitized prescription in the application as well as short message service (SMS). The doctor 110 or the nurse takes of the patient 102 receives an advance alert for medicine stock replenishment as per digitized prescriptions. In an embodiment, paid registered patients need not go to different hospitals to get a hospital registration. For example, once the patient 102 registers in the application, the patient 102 do not need to register separately to whichever hospital or doctor 110 they visit in the network.

In an embodiment, a single tap SOS bottom for emergency is tagged with global positioning system (GPS) where ambulance from nearest location reaches a patient 102 after getting confirmation and verification. In another embodiment, the patient 102 can schedule an appointment for diagnostic tests. Once the doctor 110 prescribes the medicine, the patient 102 gets to see options to select if the patient 102 wants to purchase prescribed branded drugs or generic drugs with same molecule. The patient 102 further gets to see price comparison as well. The patient 102 also has an option to select some prescribed and some generic medicines. In an embodiment, the mediclaim policy premium is reminded when required. The patient 102 gets vaccination and other alerts in advance as per digital prescription provided by the doctor 110. In an embodiment, the patient’ s 102 family also gets to see and can consult with respective doctor 110, order medication and services that is outsourced to third parties. The patient 102 is not necessary to be present at the hospital to collect diagnostic reports, the reports are updated in the application from time-to-time so that the patient education is more accurate. In an embodiment, the system 100 includes an organ transplant detailed registrar, which is synched with national organ donor’s registry are in state. The system 100 further includes live and cadaver transplant requirement and donors’ details, which saves valuable life saving time and bringing in complete transparency in the system 100.

Another embodiment of the present disclosure provides an inpatient management subsystem, which includes registration of patients 102 and allocation of bed in a ward. The inpatient management subsystem deals with complete treatment and provides services for the whole duration of the patient 102 in the hospital. The inpatient management subsystem includes conversion of inpatient to outpatient. The inpatient management subsystem maintains all the national accreditation board for hospitals and healthcare providers (NABH) and joint commission international (JCI) standards during the registration process. The inpatient management subsystem includes a radio frequency identification (RFID) wrist band for tracking patients 102 in the hospital. The inpatient management subsystem is responsible for bed allotment and bed transfer. The inpatient management subsystem includes inter department consultation. The inpatient management subsystem also includes an option for requesting drugs and consumables from the pharmacy, raising investigations and report viewing, maintenance of billing sheets for patients 102, dashboard for patient access, dashboard for billing activities or audit, dashboard for quick links such as counts, revenue, discount, and the like. The inpatient management subsystem is responsible for discharge summary. The patient 102 or patient party regularly gets serviced turnaround time (TAT) alert for clinical and non-clinical requests. In an embodiment, the patient party receives prior information on any expensive medication or treatment to be administered on the patient 102 and can digitally approve consent for the same irrespective of their physical presence in hospital premises. The patient 102 or the patient party, doctor 110, nurses are able to see live data and status of associated patient 102. The doctors 110 can change bed notes on their respective applications with the help of their hand-held devices (i.e., the user device 112). The inpatient management subsystem shows availability of blood group on demand. The inpatient management subsystem shows availability of live status of oxygen cylinders or any other associated items as desired by the patients 102 based on prescription provided by the doctor 110.

At the point of bill settlement, if there is any shortage of fund due to card limit, cash constrain and the like, the patient 102 gets an option to split the bill in parts which will be paid by their family members or friends and those payment link for that amount will go to the respective person via short message service (SMS), email, or WhatsApp. Upon successful payment the same gets updated in the system 100.

FIG. 6 consists of a process flow 600 of the doctor specific patient dashboard subsystem 206 for management of hospital, in accordance with an embodiment of the present disclosure. As per observation that at times it is observed that patients 102 are deprived from getting better care during doctor’s absence. To overcome this problem, there is a continuous synchronization algorithm 608. With the help of the synchronization algorithm 608 in the doctor specific patient dashboard subsystem 206, the patient’s data is sent to the respective doctor 110.

The synchronization process using the synchronization algorithm 608 takes place in six stages.

The doctor specific patient dashboard subsystem 206 reads all the data from the hospital management system (HMS) database that is relevant to the mobile application reformatting, condensing, and redacting as required. Next, the doctor specific patient dashboard subsystem 206 adds the delta and updates the existing records in a database table placed in a highly available cloud platform. Next, there is another user catalogue table where all the user details with their respective tenant id is inserted or updated as per hospital system management (HMS) database. The HMS database 602 includes data 602a related hospital, data 602b related to the patient 102, and data 602c related to the doctor 110. The data 602a related hospital includes a tenant_id, a hospital_id, and a hospital_name. The data 602b related to the patient 102 includes a tenant_id, a hospital_id, and a patient IP_id, iPuma_id, Staff_id. The data 602c related to the doctor 110 includes a tenant_id, a hospital_id, and a staff_id, user name (i.e., email/mobile number).

Next, the doctor specific patient dashboard subsystem 206 installed on the mobile device 112 makes an application programming interface (API) 604 call to check for updates. Next, the application programming interface (API), knowing that an updated table was generated in first step, serves up this content to the mobile device 112. Next, the doctor specific patient dashboard subsystem 206 on the mobile device 112 replaces its existing database with the newer one it just received.

The doctor specific patient dashboard subsystem 206 is configured to obtain the information related to the patient 102 from the patient registration subsystem 204 and to transmit the information related to the patient 102 to a specific healthcare provider 110 based on historical data of the patient 102 retrieved from a healthcare management database. The doctor specific patient dashboard subsystem 206 allows the healthcare provider 110 to provide digitized prescription, digitized bed notes, e-prescription to the patient 102 based on the information related to the patient 102. The specific healthcare provider 110 is authenticated 606 with details 610 comprising a list of tenants, hospitals, and corresponding data comprising email id, mobile number, and role-id;

This method using the doctor specific patient dashboard subsystem 206 reduces doctors' 110 effort to pay attention to individual patients 102. The method facilitates patient’s current information though they are admitted in different hospitals under the same doctor 110 to doctor’s mobile 112 through application. The method helps nurses to get doctor’s attention in an emergency. The doctor 110 can advise on the app when any immediate action is needed. In an embodiment, the method using the doctor specific patient dashboard subsystem 206 provides a lot of features for doctors 110. The doctors 110 gets turnaround time (TAT) alert if nursing team misses to administer any medication, conduct tests on inpatient department (IPD) patients 102. Once patient’s 102 app is live, doctors 110 can see patient's 102 captured digital health record, prior clinical history, allergy, blood group, medication, diagnostic reports- upon patient's 102 or patient party's consent. The doctors 110 can prescribe alternative medicines based on inventory availability in hospital and raise request to order certain medicines to the user accessing the pharmacy distribution management system 210. In an embodiment, the user of the pharmacy distribution management system 210 can also advise the patient 102 to choose between branded medicines or generic medicines based on patient's financial condition, healthcare scheme the patient 102 is entitled to and reducing loss of hospitals drastically.

FIG. 7 is a process flow chart 700 of admission, transfer, and discharge subsystem 216 for management of hospital, in accordance with an embodiment of the present disclosure. The admission 702, transfer that includes processes such as emergency 704a, surgery 704b, lab tests 704c, and the like, and discharge 710 processes are tracked and managed by the admission, transfer, and discharge subsystem 216. The admission, transfer, and discharge subsystem 216 enables the user to search on availability and manages the allocation of a bed 706, ward, and room to the patient 102 according to the availability or cost associated and thereby manages the transfers. The admission, transfer, and discharge subsystem 216 takes appropriate discharge procedure are followed and ensures that a comprehensive discharge summary is generated at the end.

The admission, transfer, and discharge subsystem 216 includes the comprehensive form for collection of precise data regarding the patient 102, thorough evaluation of the patient condition, recording doctors 110 and nursing notes for further management, processing orders in real time to respective departments, managing billing process, managing payments done by third parties, bed and ward allocation and transfer, e-prescription of medications.

In an embodiment, the hospital management system 106 includes a bed management subsystem that manages bed allocation 706 for the patient 102. The bed management subsystem always maintains the record of bed occupancy status. The bed management subsystem facilitates the estimation of appropriate waiting time for patients and helps in reducing the bed turnover time which is essential for optimization of revenues. The bed management subsystem also provides statistical information regarding the occupancy status of a bed over a period. The bed management subsystem includes functions such as current bed allocation status overview, monitoring and reducing the bed turnover time, scheduling the housekeeping and maintenance activities, calculation of revenue generated from each type of bed, and the like.

In another embodiment, the hospital management system 106 further includes an operating room subsystem. The operating room subsystem tracks surgeries 708 that take place in the hospital. The operating room subsystem schedules the operation, manages the surgery team, and records the surgery details to checklists associated with a surgery, and the like. The operating room subsystem manages in advance and prepares for a surgery or operation by keeping the records of all items required during the operation. The operating room subsystem enables an electronic consent of the patient 102 or the relatives. The operating room subsystem also maintains data on preoperative and postoperative conditions of the patient 102. The operating room subsystem includes functions such as accurate scheduling of the operations with flexibility in managing bookings, preoperative checklist, time out document, anesthesia record, operation record, multilingual consent forms, inventory, and stock management of the operation theatre (OT), sterilization schedules, checks and audits, and the like.

FIG. 8 is a process flow 800 for an instant admission process of the patient 102 through the patient’s personal device 104 using the admission, transfer, and discharge subsystem 216, in accordance with an embodiment of the present disclosure. As initial process, the patient 102 accessing the personal device 104 to receive details from the HMS 804 through the iPurna portal 806. The steps performed for the instant admission of the patient 102 through the patient’s personal device 104 are provided. In step 808, the patient 102 inputs the medical records and the details of the patient 102 and the medical records are validated 810 by processing/comparing 812 the previously stored data in the facility database as in step 814. In an embodiment, the validation 810 is done by checking with one time password sent to the patient 102. Upon validation, the details related to the patient 102 and the medical records are sent to the hospital emergency as in step 822. The hospital emergency tracks the patient 102 by analyzing a location of the patient 102 and allocates the bed for the patient 102 post medical check-up as in step 830. In an embodiment, the details related to the patient 102 and their medical records are temporarily stored in a cloud HNMS database as in 826.

In an embodiment, the admission, transfer, and discharge subsystem 216 enables the patient 102 to input all information including family details, prescriptions, laboratory reports, medicine intakes in advance through the patient’s personal device 104. The admission, transfer, and discharge subsystem 216 enables the patient 102 further enables the patient 102 to click an emergency admit button dedicated for each hospital, which sends an admission query to the respective hospital. The admission, transfer, and discharge subsystem 216 tracks a location 828 of the patient 102 and monitors entire way until the patient 102 reaches nearby the hospital. In an embodiment, the admission, transfer, and discharge subsystem 216 alerts the emergency staffs so that the emergency staffs get things ready to minimize time loss before admission. The emergency medical staffs examines the patient 102 and refers the respective department for treatment. The admission, transfer, and discharge subsystem 216 enables the emergency staff to click on a button to allocate a bed to the patient 102. In one embodiment, admission, transfer, and discharge subsystem 216 helps to manage all the vitals, medical records, insurance details along with identity proof are linked with the patient’s 102 in-patient record.

FIG. 9 is a process flow 900 for an instant discharge process of the patient 102 through the mobile application using the admission, transfer, and discharge subsystem 216, in accordance with an embodiment of the present disclosure. The admission, transfer, and discharge subsystem 216 stores patient’s 102 complaints, reason of admission, and medical history at the time of admission. The admission, transfer, and discharge subsystem 216 further stores clinical history, diagnosis, and procedure details during the patient 102 staying in hospital. The nurse or ward staff 902 initiates the discharge process 904 through the user device 112 in a single click. The admission, transfer, and discharge subsystem 216 enables the doctor 110 to provide a final advice to save effort, time, and cost that brings customer satisfaction (CSAT) and lower turn around time (TAT) in the whole discharge process. In an embodiment, the admission, transfer, and discharge subsystem 216 enables the doctor to provide the advice when the approval 906 received from the users from different departments such as pharmacy, lab, accounts settles the due through the respective subsystems. In an embodiment, the admission, transfer, and discharge subsystem 216 enables the ward staff/nurse the discharge summary 908 and make the patient discharge 910 from the hospital.

FIG. 10 is an exemplary view 1000 of the nursing management subsystem 208 for creating automated nursing roster, in accordance with an embodiment of the present disclosure. The nursing management system 208 prepares the nursing roster 1002 based on parameters. The nursing management system 208 calculates the parameters/details 1004 including number of nurses required 1006 in a particular ward factoring patient category 1010, number of occupied beds, information of day offs and leaves taken by the nurses during the calculation of the number of nurses required from available workforce, and information of specific skills of the nurses and the nurses for selected ward category 1008 (e.g., Operation Theatre (OT), Intensive Care Unit (ICU), Intensive Therapy Unit (ITU), and the like).

In an embodiment, the nursing management system 208 creates/prepares the nursing roster 1002 with one or more constraints that adapt linear programming to obtain most cost optimistic solutions in the hospital. The one or more constrains include at least one of: each day is divided into three 8-hour shifts 1012, every day, each shift is assigned to a single nurse, and no nurse works more than one shift, each nurse is assigned to at least two shifts during the three-day period, each nurse can have at most two shifts a day, each nurse must have at least a prespecified number of night shifts in the week, each nurse must have at least a pre-specified number of days shifts in the week, each nurse should work between a minimum and a maximum number of shifts during the planning horizon (i.e., rostering period), and the nurse should be off for next two consecutive shifts when the nurse has a shift in a specific day. In an embodiment, the nurse should be off for next three consecutive shifts when the nurse has two consecutive shifts in a specific day.

FIG. 11 is an exemplary view 1100 of the nursing management subsystem 208 for creating a nursing dashboard for management of hospital, in accordance with an embodiment of the present disclosure. The nursing management subsystem 208 helps to create the nursing keyboard that is a unique platform, where medicines to be administered, organized patient wise dynamically in every 30 minutes slab. The time slab 1102 minimizes medicine missed out incidents as well as helps nurses to administer in time resulting patient’s 102 overall healthcare improvement. In an embodiment, the nursing management subsystem 208 triggers a notification for repeated violation when the medicines are missed or administered earlier/late, which is highlighted in FIG. 11.

FIG. 12 is a process flow diagram 1200 of the pharmacy distribution management subsystem 210 for management of hospital, in accordance with an embodiment of the present disclosure. The pharmacy distribution management subsystem 210 enables the user to deal with retail sale of medicines to general customers and outpatient department (OPD) patients, and issue of medicines to the inpatients in the hospital. The pharmacy distribution management subsystem 210 has functions including online drug prescription, inventory management, billing of drugs, surgical and consumables. The pharmacy distribution management subsystem 210 includes features such as providing a comprehensive online list of available drugs for the doctors 110, displaying alternative drugs for the non-available drugs, supporting interfacing with drug databases, the first aid (ABC), vital essential desirable (VED) classification of medicines, autogeneration of alerts when minimum stock levels are reached, online requisition for stock order from the main store, provision to manage consignment items, barcode or radio frequency identification (RFID) for the items, can interact with pneumatic tube for dispatch, drug allergy alerts and the like. In case of outpatient department (OPD) consultation as soon as the outpatient department (OPD) prescription is generated, the medicines can be kept ready and thus avoid rush in pharmacy. In case of inpatient department (IPD) dept of pharmacy will directly get replenishment.

For example, the pharmacy distribution management subsystem 210 tracks or monitors the medicines provided to the in-patient or the out-patient. In step 1202, the ward staff or the nurse takes care of the in-patient returns the unused medicines. The unused returned medicines 1204 are kept at a central drug stock of the pharmacy 1206 in the hospital. The pharmacy distribution management subsystem 210 sends the information including an IPD billing to a finance department 1208 to update the bills provided to the patient 102. The pharmacy distribution management subsystem 210 tracks the stock of the medicines and sends notifications to suppliers or wholesalers to send the stock of medicines to the pharmacy as in 1206. In an embodiment, the pharmacy distribution management subsystem 210 enables the user or an expert in the pharmacy to send information of expired medicines to the suppliers or wholesalers. Further, the information related to the medicines are transmitted to an accounting department 1212 for supply invoicing and inventory purposes. In an embodiment, the medicines are transferred to a drug distribution unit as in 1204 upon the request made by the nurse or the ward staff of the IPD in 1202.

FIG. 13 is a process flow diagram 1300 of the laboratory information system subsystem 212 for management of hospital, in accordance with an embodiment of the present disclosure. The laboratory information system subsystem 212 is used by pathology lab to record and disseminate the information regarding the tests performed. A user (e.g., a laboratory personnel) in the laboratory department, using the laboratory information system subsystem 212, receives online orders from doctors 110. The laboratory information system subsystem 212 allows the laboratory personnel to generate requests including service and test setup, sponsor- wise service mapped with diagnostic tests, diagnostic packages using different tests, billing using lab orders from clinical module, requisition generation from lab order or bill, requisition creation based on facility wise, test wise, sample type wise, sample collection process, and interfacing with lab analysers. The laboratory information system subsystem 212 further includes fetching results from analyser data, rechecking the results, results authorization, redo process from sample collection, status update, prints with national accreditation board for testing and calibration laboratories (NABL) standards, print queue process, access previous lab results based on tests and unique hospital identification number (UHID) number, lab reagents and kits inventory management, dashboard for authorization, dashboard for turnaround time (TAT), dashboard for work in progress, analysis of dashboard based on parameters and tests. The laboratory personnel using the laboratory information system subsystem 212 gets leads when the patient 102 books or schedule a test. In an embodiment, the laboratory personnel directly sends reports, through the laboratory information system subsystem 212, to the doctors 110, the patient 102 and the patient parties which will be updated in application of respective people. In an embodiment, all diagnostics reports are dispatched digitally or electronically to patients 102.

The laboratory information system subsystem 212 enables the user or the expert in the lab of the hospital to perform lab related processes for the in-patient as well as the out-patients. In an embodiment, the steps related to the lab processes performed for the out-patient are provided. At step 1312, the laboratory information system subsystem 212 determines whether the test is done in-house upon consultant prescription at 1306, pathology registration 1308 and bill generation 1310 for in-house, or outsourced service. If the laboratory information system subsystem 212 determines the test belongs to the in-house test, the information of a sample is collected with a barcode as in 1314 and the same is sorted with a batch as in 1316. The user or expert in laboratory receives the sample as in 1320 for test as in 1322. The laboratory information system subsystem 212 updates records based on the sample and displays to the patient 102 as in 1326. If the test is not belonging to in-house then the sample is collected by a third party outside from the hospital as in 1328 and the laboratory information system subsystem 212 determines whether sample is eligible for testing in 1330. The laboratory information system subsystem 212 sends the report to the patient 102 in various formats including PDF format/specified template (e.g., json/xml/csv), and the like.

In another embodiment, the steps related to the lab processes performed for the out-patient are provided. At step 1338, the doctor 110 inputs the medical test in a Bednote of the in-patient. The laboratory information system subsystem 212 enables the user/expert in the laboratory receives requisition from the nurse/ward staff in 1342. A barcode is generated for the in-patient 102 upon receiving the information from the nurse/ward staff as in 1344. A sample is collected at bed and labelled by the barcode sticker as in 1346. The laboratory information system subsystem 212 determines the test belongs to the in-house test as in 1348. If the laboratory information system subsystem 212 determines the test belongs to the in-house test, then the user/expert in the laboratory receives the sample in 1350 and test the sample as in 1352. The laboratory information system subsystem 212 enables the user to provide the results in the patient’s 102 records that are viewed by the doctor 110 or the nurse for further treatments. If the test is not belonging to in-house then the sample is collected by a third party outside from the hospital as in 1328 and the laboratory information system subsystem 212 determines whether sample is eligible for testing in 1330. The laboratory information system subsystem 212 sends the report to the patient 102 in various formats including PDF format/specified template (e.g., json/xml/csv), and the like upon completion of the test in 1332. The test results are then sent to the corresponding doctor 110, nurse or ward staff who takes care of the inpatient 102.

FIG. 14 is a process flow 1400 for the inventory management subsystem 222 for management of hospital, in accordance with an embodiment of the present disclosure, the inventory management subsystem 222 enables the user to deal with purchase and supply of the hospital equipment or material or inventory to different departments. Requisitions for different items or equipment’s are sent to this store from different departments. The inventory management subsystem 222 includes features such as a supplier management, a location management including warehouses, sub stores, departments, stock points, crash carts and the like. The inventory management subsystem 222 also includes preparation of various warehouses for general items, drugs, assets, surgical items, and the like. In an embodiment, the inventory management subsystem 222 includes protocols for purchase, stocking, stock tracking and verifications, distribution, sales. For example, the inventory management subsystem 222 includes today’s transactions reports. The digital geo tag based live status of inventory in the nearest location makes it visible on demand or by default the availability of essential medicine and associated items in nearby networked pharmacies.

The inventory management subsystem 222 further includes features including a supplier 1402, a purchase department 1404, a central store 1406, and a ward store. The inventory management subsystem 222 manages the provision of medicines to the patient 102, and the manages purchasing of the medicines from the supplier 1402, and stocks of the medicines in the hospital by following steps. At step 1410, the inventory management subsystem 222 enables the expert in the purchase department to order the medicines to the supplier 1402. At step 1412, the central store 1406 receives the medicines and checks the medicines. The inventory management subsystem 222 enables the expert in the central store to check whether the medicines are same as ordered by the expert as in 1414. If yes, the medicines are stored in a stock-room. If no, the medicines are returned to the supplier 1402 as in step 1416. The supplier 1402 then reviews the returned medicines and amends changes.

At step 1418, the inventory management subsystem 222 enables the nurse or ward staff to prepare the medicines for the patient 102. Further, the inventory management subsystem 222 enables the nurse or ward staff to check whether there are enough stock the medicines for one day usage at step 1420. If yes, the process ends. If no, the inventory management subsystem 222 enables the nurse or ward staff to fill an internal request form as in step 1422 and send the filled form to the central store 1406 as in step 1424. The nurse or ward staff then receives the medicines and stores in ward store upon sending the request as in step 1426.

FIG. 15 is a reference model diagram 1500 in estimating a cost for medical treatments using the medical treatment cost assessor subsystem 214 with a deep machine learning algorithm 1506, in accordance with an embodiment of the present disclosure. The medical treatment cost assessor subsystem 214 estimates cost for medical treatments comprising procedure and day care treatments 1502 and longer stay treatments 1504 provided to the patient 102 using a deep machine learning algorithm 1506. The medical treatment cost assessor subsystem 214 with the deep machine learning algorithm 1506 estimates the cost for medical treatment by (a) obtaining charges table for different basic procedures and day care medical treatment facilities, (b) analysing diagnosis 1508 and disease wise day stay (e.g., treatment history 1510) with list of services to be offered (e.g., vitals collected 1512 from the patient 102) to the patient 102, (c) performing analysis and comparison-based learning from services provided for identical diseases and diagnosis, and (d) assessing insurance cost based on learning and the medical treatments offered to the patient 102.

FIG. 16 illustrates a reference model diagram 1600 in decision making for management of hospital, in accordance with an embodiment of the present disclosure. The reference model diagram 1600 shows the medical diagnosis 1612, treatment selection 1616, patient prognosis including patient’s 102 previous records, symptoms, and collected vitals 1606, discharge 1626, and patient transfer information and the selection of appropriate medical procedures. In an embodiment, the above said processes are performed by the clinical decision support subsystem (CDSS) 224 that is integrated in the hospital management system 106. With this clinical decision support system 224, the successful combination of the physician’s cognition 1622 with the available clinical information (i.e., clinical protocols) 1624 that brings an expected outcome. In an embodiment, the system 100 creates a unique health ID in SaaS based hospital management system 106. The hospital management system 106 captures detail address with ZIP/PIN of the patient 102 and verifies along with patient’s other information including name, age, sex, email, mobile number, which are stored and encrypted in an in-patient and an outpatient database 1602. The hospital management system 106 captures correct ICD code against diagnosis. In an embodiment, the captured data are channelized through an Al driven functionality 1618, which filters out chronic ailment from patient’s earlier clinical history (EHR).

Data subsets are driven through an analytical method to classify diagnosis wise patient count on a particular locality (i.e., block/subdivision/district/division/state) as in 1620. The hospital management system 106 checks similar occurrence in near past with average recovery time. Interconnected medical service provider’s service availability (e.g., availability of bed, oxygen, blood, medicine, and the like) are also collected to forecast demand-supply gap. In an embodiment, same availability information is conveyed to patient 102 through SMS for quick reference. In another embodiment, substantial surge in count will raise alert for government agencies on possible health crisis and advance arrangement.

FIG. 17 is a block diagram 1700 of the clinical decision support subsystem (CDSS) 224 for management of hospital, in accordance with an embodiment of the present disclosure. In an embodiment, the clinical decision support subsystem 224 is integrated with the hospital management system (HMS) 106 based on technical aspects. The clinical decision support subsystem 224 prepares its knowledge base from an electronic medical record (EMR) structured and unstructured data along with clinical protocols, its administration, results, and recovery. The clinical decision support subsystem 224 includes its own mechanism to enrich and purify data with relevant input from various world medical research institutions over web application programming interface (API). The clinical decision support subsystem 224 further supports physicians on diagnosing patients applying artificial intelligence on its knowledge base with fuzzy search based on provided input. FIG. 18 is a computer implemented method 1800 for managing healthcare data and end-to-end hospital management using a hospital management system 106, in accordance with an embodiment of present disclosure. At step 1802, the patient registration subsystem 204 obtains information related to a patient 102 upon registration by the patient 102. The information related to the patient 102 includes at least one of vital tests of the patient 102, demographic information of the patient 102 including a name, an address, a gender of the patient 102, and previous medical history of the patient 102. At step 1804, the doctor specific patient dashboard subsystem 206 obtains the information related to the patient 102 from the patient registration subsystem 204. At step 1806, the doctor specific patient dashboard subsystem 206 transmits the information to a specific healthcare provider 110 based on historical data of the patient 102 retrieved from a healthcare management database. In an embodiment, the doctor specific patient dashboard subsystem 206 allows the healthcare provider 110 to provide digitized prescription, digitized bed notes, e-prescription to the patient 102 based on the information related to the patient 102. In another embodiment, the specific healthcare provider 110 is authenticated with details comprising a list of tenants, hospitals, and corresponding data comprising email id, mobile number, and role-id.

At step 1808, the nursing management subsystem 208 obtains regular turnaround time (TAT) alerts for every patient 102 with patient identification (ID) or name, bed number, and room number based on the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider 110 to perform activities comprising time to time medication, checking vitals, and recording readings from display monitors. At step 1810, the pharmacy distribution management subsystem 210 obtain inputs from the nursing management subsystem 208 and analyses the inputs to distribute medicines to the patient 102. At step 1812, the pharmacy distribution management subsystem 210 compares the input comprising the data related to the digitized prescription, the digitized bed notes, and the e-prescription provided by the healthcare provider 110 with data related to medicines and equipment stored in a pharmacy. At step 1814, the laboratory information subsystem 212 receives orders from the healthcare provider 110 and to allow a user to generate requests to process results based on data related to a sample received from the patient 102. At step 1816, the medical treatment cost assessor subsystem 214 estimates cost for medical treatments comprising procedure and day care treatments and longer stay treatments provided to the patient 102 using a deep machine learning algorithm 1506 by (a) obtaining charges table for different basic procedures and day care medical treatment facilities, (b) analysing diagnosis and disease wise day stay with list of services to be offered to the patient 102, (c) performing analysis and comparison-based learning from services provided for identical diseases and diagnosis, and (d) assessing insurance cost based on learning and the medical treatments offered to the patient 102.

The present disclosure provides the hospital management system 106 to automate the workflow efficiently around the labs, and hospital, and to streamline different procedures, hospital management system 106 came into existence.

The present invention further provides the healthcare or hospital management system 106 which manages, organizes, and provides all information in one place. The system 100 provides a platform integrated with a web application and a mobile application to eliminate the sole dependency of hard copy use. The system 100 makes the process simpler and gives smooth experience to patients 102 and healthcare professional 110. Further, the system 100 saves time and cost effective. The system 100 also manages and covers holistically all verticals associated and related to healthcare system, make healthcare delivery convenient, simpler, faster, and efficient.

The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.

The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, and the like. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random-access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

Input/output (VO) devices (including but not limited to keyboards, displays, pointing devices, and the like.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

A representative hardware environment for practicing the embodiments may include a hardware configuration of an information handling/computer system in accordance with the embodiments herein. The system herein comprises at least one processor or central processing unit (CPU). The CPUs are interconnected via system bus 208 to various devices such as a random-access memory (RAM), read-only memory (ROM), and an input/output (VO) adapter. The VO adapter can connect to peripheral devices, such as disk units and tape drives, or other program storage devices that are readable by the system. The system can read the inventive instructions on the program storage devices and follow these instructions to execute the methodology of the embodiments herein.

The system further includes a user interface adapter that connects a keyboard, mouse, speaker, microphone, and/or other user interface devices such as a touch screen device (not shown) to the bus to gather user input. Additionally, a communication adapter connects the bus to a data processing network, and a display adapter connects the bus to a display device which may be embodied as an output device such as a monitor, printer, or transmitter, for example.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article, or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, and the like, of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.