System and method for generating synthetic data for hospital patient flow simulation

Abstract

A system and method generate synthetic data simulating patient flow in a hospital for a simulation to provide hospital operations analytics. The method includes populating a hospital configuration file by specifying hospital parameters to provide data specific to the hospital and simulation criteria; populating arrival configuration files by specifying arrival parameters for arrival modules, where each arrival module includes corresponding constraints, and is configured to generate a base waveform to capture corresponding arrival patterns or a schedule; generating a patient trajectory for each arrival module based on the base waveform or the schedule, and the data specific to the hospital from the hospital configuration file; integrating the patient trajectories to provide an integrated patient trajectory including synthetic data specific to the patient flow in the hospital; and applying the integrated patient trajectory to an analytics algorithm to enable realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies.

Description

[0001] SYSTEM AND METHOD FOR GENERATING SYNTHETIC DATA FOR HOSPITAL PATIENT

[0002] FLOW SIMULATION

[0003] BACKGROUND OF THE INVENTION

[0004] The use of analytics has increased over the past decade to help improve hospital operations, including care and treatment of patients. Generally, hospital patient flow simulations may be used to predict key operating conditions, such as bottlenecks and staffing needs, for example. However, calibrating the patient flow simulations implemented by artificial intelligence (Al), in particular, requires adequate data from the hospitals, which is often difficult to obtain. In addition, the patient flow simulations may be used to test scenarios that might occur, i.e., “what if’ scenarios, but this too requires either finding sufficient data in historical records describing such scenarios or creating the data de novo.

[0005] The role of synthetic data in Al research has recently expanded. This is particularly true for clinical data, where privacy restrictions and disparate data systems create barriers to acquiring data to adequately train Al clinical analytics, thereby causing the quality of the Al clinical analytics performance and results to suffer. However, most studies have focused on representation of clinical data with relatively few attempts to generate realistic operational and procedural clinical data. Again, the more realistic the data, the greater the improvement in functionality of the Al clinical analytics.

[0006] For example, the patient flow capacity suite (PFCS) is a cloud-based logistics management solution, available from Koninklijke Philips N.V., which offers hospital operations analytics in order to provide situational awareness, staff planning, resource allocation, and the like to improve patient care and treatment. Since no two hospitals are the same, several of the PFCS analytics require historical data from each hospital for calibration and for making accurate predictions. However, the historical data may not be readily available from the hospitals and may be incomplete or otherwise insufficient for proper training, which becomes a barrier to deploying the solution.

[0007] Therefore, it would be advantageous if realistic synthetic data could be created reliably for calibration, training and scenario testing for Al analytics algorithms, including machine learning algorithms, without having to rely on actual data acquired from the hospitals. Such data would improve functionality of the Al analytics algorithms, which in turn would provide critical capability to hospital flow simulation technology.

[0008] SUMMARY OF THE INVENTION

[0009] According to a representative embodiment, a method is provided for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital. The method includes populating a hospital configuration file by specifying multiple hospital parameters to provide data specific to the hospital, including patient data, ward capacity data indicating capacity of at least somewards, such as one ward and preferably all wards, in the hospital, and ward occupancy data indicating occupancy of each ward in the hospital, and by specifying simulation criteria including at least a time length of the simulation, ward capacity data indicating capacity of wards in the hospital, and ward occupancy data indicating occupancy of the wards in the hospital; populating multiple arrival configuration files by specifying multiple arrival parameters for the arrival modules, respectively, where each arrival module includes at least one corresponding constraint, and is configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint or to generate a schedule based on the at least one corresponding constraint; generating a patient trajectory for each arrival module of the multiple arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file; integrating the patient trajectories from the arrival modules to provide an integrated patient trajectory including synthetic data specific to the patient flow in the hospital; and applying the integrated patient trajectory to an Al analytics algorithm to enable realistic situational simulations, staff planning, resource allocation, and / or simulated remediation strategies to alleviate overcrowding of the hospital.

[0010] According to a representative embodiment, a computer-implemented method of generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital is described, the method comprises populating a hospital configuration file by specifying a plurality of hospital parameters to provide data specific to the hospital, including at least one of: patient data, ward capacity data indicating capacity of at least one ward of a plurality of wards in the hospital, ward occupancy data indicating occupancy of at least one ward of the plurality of wards,, ward capacity data indicating capacity of wards in the hospital by specifying simulation criteria including at least a time length of the simulation and ward occupancy data indicating occupancy of the wards in the hospital. Further the method at least in some embodiments comprises populating a plurality of arrival configuration files by specifying a plurality of arrival parameters for a plurality of arrival modules, wherein the plurality of arrival modules comprise at least one constraint, the plurality of arrival modules configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint, or configured to generate a schedule based on the at least one corresponding constraint; Further at least generating at least one patient trajectory for at least one arrival module of the plurality of arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file, integrating the at least one patient trajectory from the plurality of arrival modules to provide an integrated patient trajectory comprising synthetic data specific to the patient flow in the hospital and applying an analytics algorithm to the integrated patient trajectory for providing realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies in a hospital workflow. According to a representative embodiment, a non-transitory computer readable storage medium or computer readable medium stores instructions for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital. When executed by a processor, the instructions cause the processor to populate a hospital configuration file by specifying hospital parameters to provide data specific to the hospital, including patient data, ward capacity data indicating capacity of at least one ward of multiple wards in the hospital, and ward occupancy data indicating occupancy of at least one ward of multiple of the wards, and by specifying simulation criteria including at least a time length of the simulation, ward capacity data indicating capacity of wards in the hospital, and ward occupancy data indicating occupancy of the wards in the hospital; populate multiple arrival configuration files by specifying multiple arrival parameters for multiple arrival modules, respectively, where an arrival module includes at least one corresponding constraint, and is configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint or to generate a schedule based on the at least one corresponding constraint; generate a patient trajectory for at least one arrival module, preferably for each arrival module, of the multiple arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file; integrate the patient trajectories from the multiple arrival modules to provide an integrated patient trajectory comprising synthetic data specific to the patient flow (e.g., indicative of the patient flow) in the hospital; and apply the integrated patient trajectory to an analytics algorithm to enable realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies to alleviate overcrowding of the hospital.

[0011] According to a representative embodiment, a system is provided for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital. The system includes a processor; a user interface configured to enable interaction between a user and the processor; and a memory connected to the processor and storing instructions. When executed by the processor, the instructions cause the processor to populate a hospital configuration file by specifying hospital parameters to provide data specific to the hospital, including patient data, ward capacity data indicating capacity of at least one ward of multiple wards in the hospital, and ward occupancy data indicating occupancy of at least one ward of the multiple wards, and by specifying simulation criteria including at least a time length of the simulation, ward capacity data indicating capacity of wards in the hospital, and ward occupancy data indicating occupancy of the wards in the hospital; populate multiple arrival configuration files by specifying multiple arrival parameters for multiple arrival modules, respectively, where each arrival module includes at least one corresponding constraint, and is configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint or to generate a schedule based on the at least one corresponding constraint; generate a patient trajectory for each arrival module of the multiple arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file; integrate the patient trajectories from the multiple arrival modules to provide an integrated patient trajectory comprising synthetic data specific to the patient flow in the hospital; and apply the integrated patient trajectory to an analytics algorithm to enable realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies to alleviate overcrowding of the hospital.

[0012] BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The example embodiments are best understood from the following detailed description when read with the accompanying drawing figures. It is emphasized that the various features are not necessarily drawn to scale. In fact, the dimensions may be arbitrarily increased or decreased for clarity of discussion. Wherever applicable and practical, like reference numerals refer to like elements.

[0014] Fig. 1 is a simplified block diagram of a system for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, according to a representative embodiment.

[0015] Fig. 2 is a flow diagram of a method of generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, according to a representative embodiment.

[0016] Fig. 3A is a flow diagram of a method of generating a patient trajectory for simulating emergency department admissions, according to a representative embodiment.

[0017] Fig. 3B is a flow diagram of a method of generating a patient trajectory for simulating direct admissions, according to a representative embodiment.

[0018] Fig. 3C is a flow diagram of a method of generating a patient trajectory for simulating transfer center admissions, according to a representative embodiment.

[0019] Fig. 3D is a flow diagram of a method of generating a patient trajectory for simulating surgical center operations, according to a representative embodiment.

[0020] DETAILED DESCRIPTION OF EMBODIMENTS

[0021] In the following detailed description, for purposes of explanation and not limitation, representative embodiments disclosing specific details are set forth in order to provide a thorough understanding of an embodiment according to the present teachings. Descriptions of known systems, devices, materials, methods of operation and methods of manufacture may be omitted so as to avoid obscuring the description of the representative embodiments. Nonetheless, systems, devices, materials and methods that are within the purview of one of ordinary skill in the art are within the scope of the present teachings and may be used in accordance with the representative embodiments. It is to be understood that the terminology used herein is for purposes of describing particular embodiments only, and is not intended to be limiting. The defined terms are in addition to the technical and scientific meanings of the defined terms as commonly understood and accepted in the technical field of the present teachings.

[0022] It will be understood that, although the terms first, second, third etc. may be used herein to describe various elements or components, these elements or components should not be limited by these terms. These terms are only used to distinguish one element or component from another element or component. Thus, a first element or component discussed below could be termed a second element or component without departing from the teachings of the inventive concept.

[0023] The terminology used herein is for purposes of describing particular embodiments only, and is not intended to be limiting. As used in the specification and appended claims, the singular forms of terms “a,” “an” and “the” are intended to include both singular and plural forms, unless the context clearly dictates otherwise. Additionally, the terms “comprises,” and / or “comprising,” and / or similar terms when used in this specification, specify the presence of stated features, elements, and / or components, but do not preclude the presence or addition of one or more other features, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0024] Unless otherwise noted, when an element or component is said to be “connected to,” “coupled to,” or “adjacent to” another element or component, it will be understood that the element or component can be directly connected or coupled to the other element or component, or intervening elements or components may be present. That is, these and similar terms encompass cases where one or more intermediate elements or components may be employed to connect two elements or components. However, when an element or component is said to be “directly connected” to another element or component, this encompasses only cases where the two elements or components are connected to each other without any intermediate or intervening elements or components.

[0025] As used in the specification and appended claims, and in addition to their ordinary meanings, the term “about” and “approximately” mean to with acceptable limits or degree. For example, “approximately 2 MHz” means one of ordinary skill in the art would consider the signal to be 2 MHz within reasonable measure. Also, as used in the specification and appended claims, in addition to its ordinary meaning, the term “substantially” means within acceptable limits or degree. For example, the term “substantially simultaneously” means one of ordinary skill in the art would consider occurrence at the same time.

[0026] In view of the foregoing, the present disclosure, through one or more of its various aspects, embodiments and / or specific features or sub-components, is thus intended to bring out one or more of the advantages as specifically noted below. For purposes of explanation and not limitation, example embodiments disclosing specific details are set forth in order to provide a thorough understanding of an embodiment according to the present teachings. However, other embodiments consistent with the present disclosure that depart from specific details disclosed herein remain within the scope of the appended claims. Moreover, descriptions of well-known apparatuses and methods may be omited so as to not obscure the description of the example embodiments. Such methods and apparatuses are within the scope of the present disclosure.

[0027] Generally, the various embodiments at least in some instances provide for a software platform (e.g., data synthesizer) that allows creation of synthetic data specified by a user, which may be used for improved calibration and training of Al analytics algorithms, as well as improved scenario testing and predictions by the calibrated and trained Al analytics algorithms, such as PFCS census predictions, for example. With only qualitative knowledge of anticipated hospital operations data, the user is able to create realistic arrival and census data. This is possible because the data synthesizer is built using realistic operational constraints derived from specialized data and knowledge. The data synthesizer may also be used to create operations data sets for the purpose of algorithm development and potentially combining with de-anonymized clinical data to generate semi-synthetic comprehensive hospital datasets.

[0028] The embodiments generate calibration and training data for patient flow simulation technology, as well as realistic hospital data for “what if’ scenario testing, such as “what if the intensive care unit (ICU) is at capacity” or “what if emergency department arrivals double on a Friday,” for example. In addition, the embodiments may generate specific customized operational and clinical datasets with added privacy protection.

[0029] Creating synthetic data requires accurate descriptions of multiple key processes. The key processes include, for example, configuring arrival paterns, patient stay paterns, and other synthetic inputs while also adhering to realistic hospital constraints. The parameterization and integration of these key processes is challenging. The embodiments described herein outline how to accomplish parameterization, with emphasis on emergency arrivals, direct admission arrivals, transfer patient arrivals, and scheduled surgery arrivals. The overall framework is flexible, in that it may be applied across different hospital configurations, such as different wards, different numbers of beds, and the like. Hospital constraints are applied to ensure the data maintain a realistic representation of the hospital.

[0030] Fig. 1 is a simplified block diagram of a system for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, according to a representative embodiment.

[0031] Referring to Fig. 1, system 100 includes a workstation 105 for implementing and / or managing the processes described herein. The workstation 105 includes processor 120, memory 130, a user interface 122 and a display 124. The memory 130 stores instructions executable by the processor 120. When executed, the instructions cause the processor 120 to implement one or more processes for automatically generating synthetic data pertaining to occupancy and flow of patients in a hospital. For purposes of illustration, the memory 130 is shown to include software modules, each of which includes sets of instructions, executable by the processor 120, corresponding to an associated capability of the system 100.

[0032] The synthetic data is electronic data that may be used as input to Al algorithms for planning, testing and medical treatment, where no or insufficient actual data exists for performing meaningful simulations and / or predictions. Also, in an embodiment, the synthetic data may be derived in part from actual clinical data without compromising privacy of patients with whom the actual clinical data is associated. Because the synthetic data is entirely electronic, generating the synthetic data and / or patient trajectories comprising the synthetic data cannot be performed in the human mind. Also, generating the synthetic data is an improvement in the technical field of computer implemented simulating and modeling, where conventional systems relied on actual data or modeled data that inadequately represented desired datasets.

[0033] The processor 120 is representative of one or more processing devices, and may be implemented by a general purpose computer, a central processing unit (CPU), a digital signal processor (DSP), a graphical processing unit (GPU), a tensor processing unit (TPU), a computer processor, a microprocessor, a state machine, programmable logic device, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or combinations thereof, using any combination of hardware, software, firmware, hard-wired logic circuits, or combinations thereof. Any processor or processing unit herein may include multiple processors, parallel processors, or both. Multiple processors may be included in, or coupled to, a single device or multiple devices. The term “processor” as used herein encompasses an electronic component able to execute a program or machine executable instruction. A processor may also refer to a collection of processors within a single computer system or distributed among multiple computer systems, such as in a cloud-based or other multi-site application. Programs have software instructions performed by one or multiple processors that may be within the same computing device or which may be distributed across multiple computing devices.

[0034] The memory 130 is representative of one or more memories, and may include main memory and / or static memory, where such memories may communicate with each other and the processor 120 via one or more buses. The memory 130 may be implemented by any number, type and combination of random access memory (RAM) and read-only memory (ROM), for example, and may store various types of information, such as software algorithms, artificial intelligence (Al) models including machine learning and / or rule based models, and computer programs, all of which are executable by the processor 120. The various types of ROM and RAM may include any number, type and combination of computer readable storage media, such as a disk drive, flash memory, an electrically programmable read-only memory (EPROM), an electrically erasable and programmable read only memory (EEPROM), registers, a hard disk, a removable disk, tape, compact disk read only memory (CD- ROM), digital versatile disk (DVD), floppy disk, Blu-ray disk, a universal serial bus (USB) drive, or any other form of storage medium. The memory 130 is a tangible storage medium for storing data and executable software instructions, and is non-transitory during the time software instructions are stored therein. As used herein, the term “non-transitory” is to be interpreted not as an eternal characteristic of a state, but as a characteristic of a state that will last for a period. The term “non-transitory” specifically disavows fleeting characteristics such as characteristics of a carrier wave or signal or other forms that exist only transitorily in any place at any time. The memory 130 may store software instructions and / or computer readable code that enable performance of various functions. The memory 130 may be secure and / or encrypted, or unsecure and / or unencrypted.

[0035] The system 100 may also include database 112 for storing information that may be used by the various software modules of the memory 130, and for populating various configuration files, including hospital configuration file 141, discussed below. For example, the database 112 may include hospital data, including facilities data, administrative data, and patient records, such as an electronic health records (EHR) database, for example. The database 112 may be implemented by any number, type and combination of RAM and ROM, for example. The various types of ROM and RAM may include any number, type and combination of computer readable storage media, such as a disk drive, flash memory, EPROM, EEPROM, registers, a hard disk, a removable disk, tape, CD-ROM, DVD, floppy disk, Blu-ray disk, USB drive, or any other form of storage medium known in the art. The database 112 comprises tangible storage mediums for storing data and executable software instructions and is non-transitory during the time data and software instructions are stored therein. The database 112 may be secure and / or encrypted, or unsecure and / or unencrypted. For purposes of illustration, the database 112 is shown as a separate storage medium, although it is understood that it may be combined with and / or included in the memory 130, without departing from the scope of the present teachings.

[0036] The processor 120 may include or have access to an artificial intelligence (Al) engine for executing one or more Al analytics algorithms, which may be implemented as software that provides artificial intelligence (e.g., machine learning models and / or rule based models) described herein. The Al engine may reside in any of various components in addition to or other than the processor 120, such as the memory 130, an external server, and / or the cloud, for example. When the Al engine is implemented in a cloud (not shown), such as at a data center, for example, the Al engine may be connected to the processor 120 via the internet or other communication network using one or more wired and / or wireless connection(s).

[0037] The user interface 122 is configured to provide information and data output by the processor 120 and / or the memory 130 to the user, and / or for receiving information and data input by the user. That is, the user interface 122 enables the user to enter data and to control or manipulate aspects of the processes described herein, and also enables the processor 120 to indicate the effects of the user’s input. All or a portion of the user interface 122 may be implemented by a graphical user interface (GUI), such as GUI 128 viewable on the display 124, discussed below. The user interface 122 may include one or more interface devices, such as a mouse, a keyboard, a trackball, a joystick, a microphone, a video camera, a touchpad, a touchscreen, voice or gesture recognition captured by a microphone or video camera, for example.

[0038] The display 124 may be a monitor such as a computer monitor, a television, a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, or a cathode ray tube (CRT) display, or an electronic whiteboard, for example. The display 124 includes a screen 126 for viewing information determined by the processor 120 or stored in the memory 130, including various features described herein with regard to outputting synthetic data pertaining to occupancy and flow of patients in the hospital to enable simulation of patient flow. The screen 126 further enables viewing of the GUI 128 to enable the user to interact with displayed images and features.

[0039] Referring to the memory 130, the various modules therein store sets of data and instructions executable by the processor 120 to determine a procedure for generating synthetic data. Included in the memory 130 is synthetic data generation module 131 configured to generate and output realistic synthetic data pertaining to occupancy and flow of patients in the hospital based on constraints specific to the hospital and user specified parameters. In particular, the synthetic data generation module 131 is configured to apply an integrated patient trajectory algorithm that inputs multiple arrival patient trajectories, which are output by corresponding arrival modules directed to different simulated patient arrival scenarios, and outputs an integrated patient trajectory as the synthetic data. In the depicted embodiment, the arrival modules include emergency department (ED) arrival module 132, direct admission (DA) arrival module 133, transfer center (TC) arrival module 134, and surgical cases (SC) arrival module 135, discussed below, although other department modules may be included without departing from the scope of the present teachings. The integrated patient trajectory algorithm may be a rule based algorithm, for example, which incorporates a set of prewritten rules to make decisions regarding the synthetic data. The rules may be created based on human expert knowledge, and an inference engine measures the arrival patient trajectories against the set of rules to produce the integrated patient trajectory. The rules may be encoded in the form of if-then statements, for example. The rule based algorithm is particularly useful in the absence of sufficient realistic data, since without realistic data, a machine learning model cannot be properly trained. Providing the synthetic data to the machine learning model improves performance and results of the machine learning model. Generation of the synthetic data cannot practically be performed in the human mind, especially where the synthetic data is generated by applying a base waveform. Additional or alternative arrival modules may be incorporated without departing from the scope of the present teachings.

[0040] The synthetic data generation module 131 is in communication with hospital configuration file 141, which embodies specialized knowledge and constraints regarding the hospital and its operations to ensure generation of realistic synthetic data, as well as user configurable parameters for customizing the synthetic data. The user may specify parameters of the hospital configuration file 141 by populating the files themselves or via the GUI 128. For example, hospital configuration file 141 may be a text file, in which case the user may open the text file and enter the parameters into the text file. In an embodiment, the synthetic data generation module 131 may provide a template of parameters for the hospital configuration file 141, where the user may enter parameter values to populate the template via the GUI 128, for example. The selection and inclusion of the parameters in the hospital configuration file 141 represent specialized knowledge of the hospital. The constraints include fixed information about the hospital itself, such as the number and types of wards, ward capacity limits, overflow policies, scheduling limitations, and the like. The synthetic data generation module 131 receives the patient trajectories from the corresponding arrival modules, and integrates these patient trajectories to generate the integrated patient trajectory. The patient trajectory might relate to any one of or combination of: patient (previous) disease, patient state, patient inward time and discharge time, point of diagnosis of the patient (e.g., suspected disease), recorded health events over time (e.g., through electronic health records, wearables, or other sensing technologies), Electronics Medical Record (EMR) information and Electronic Health Record (EHR) information including patient physical information (e.g., weight), patient workflow analysis (e.g., prescribed procedures), and other relevant information for patient trajectories. The output of the synthetic data generation module 131 may be patient level data in a csv fde, for example, describing simulated patient stays in the hospital that incorporates information specific not only to the hospital, but also to different modes of entering the hospital.

[0041] Non-limiting examples of configurable parameters that may be populated by the user in the hospital configuration file 141 are shown in Table 1, below. Of course, additional or fewer hospital configuration file parameters, as well as different hospital configuration file parameters, may be incorporated without departing from the scope of the present teachings.

[0042] Table 1

[0043] In the depicted embodiment, the synthetic data generation module 131 is also in communication with transition probabilities configuration file 142 and length of stay (LOS) configuration file 143. The transition probabilities configuration file 142 outputs additional information that describes transition probabilities of patients transferring between wards within the hospital, and the LOS configuration file 143 outputs likely lengths of stay of patients in the different wards. The transition probabilities configuration file 142 and the LOS configuration file 143 may likewise include corresponding templates to be populated by the user.

[0044] More particularly, the transition probabilities configuration file 142 includes configurable parameters that identify all the wards present in the hospital, and may be structured as individual dictionaries respectively corresponding to the wards. Each dictionary consists of the transition probability of a patient going from the corresponding ward to any other ward in the hospital. For surgical cases, in particular, the transition probabilities may be defined based on the types of surgery. For example, when the initial ward is “OR” (operating room) and the surgery type is “Neuro” (neurosurgery) the probability of a patient moving to the “ICU” (intensive care unit) ward is higher than when the initial ward is “OR” and the surgery type is “General.” Capturing the transition probabilities therefore makes the ward sequences more realistic and the tool more robust. The transition probabilities configuration file 142 is populated holistically for the entire hospital, even for wards that do not have corresponding arrival modules (e.g., radiology), so that there is consistency across all wards of the hospital and no discontinuities or disagreements.

[0045] The LOS configuration file 143 includes configurable parameters for generating individual patient lengths of stay. The length of stay for a patient may be generated according to multiple different processes, which may be based on statistical probability distributions, for example, along with lists of the required parameters. Other mathematical formulations may be used, including models that take patient physiology and health as input, without departing from the scope of the present teachings.

[0046] There are three illustrative options for generating patient length of stay information based on statistical probability distributions, which have corresponding parameters in the LOS configuration file 143 to be populated by the user. The first option provides a fixed value, where the LOS parameter is set to a fixed value, e.g., given by a “fixed LOS” parameter, indicating the length of stay in a particular ward in the LOS configuration file 143. Each ward may have a different fixed value for the corresponding patient LOS, which may be estimated or determined empirically, for example. The second option provides a random lognormal distribution, according to which a random number is extracted from a log normal distribution of LOS values of the wards with mean and standard deviation parameters set according to given “mu” and “sigma” parameters, where “mu” is the mean value of the respective distribution from which the LOS value is extracted, and “sigma” is the standard deviation value of the respective distribution from which the LOS value is extracted. The third option provides an exponential distribution, according to which a random number is extracted from an exponential distribution of LOS values with the mean and standard deviation parameters set according to the given “mu” and “sigma” parameters. Each ward in the hospital has its own set of parameters. Additional configurable parameters may include “min,” which is the minimum bound of the LOS (i.e., the LOS value should not go below this parameter, and if it does it is automatically adjusted to the value of “min”), and “max,” which is the maximum bound of the LOS (i.e., the LOS value should not go above this parameter, and if it does it is automatically adjusted to the value of “max”).

[0047] As mentioned above, the synthetic data generation module 131 is in communication with the ED arrival module 132, the DA arrival module 133, the TC arrival module 134, and the SC arrival module 135. Additional or fewer arrival modules, as well as different arrival modules, may be incorporated without departing from the scope of the present teachings. The specialized nature of the data is considered for each of these arrival modules. Each of the ED arrival module 132, the DA arrival module 133, the TC arrival module 134, and the SC arrival module 135 may likewise include corresponding templates to be populated by the user based on specialized knowledge associated with each.

[0048] The ED arrival module 132 is configured to apply an ED algorithm that generates the arrival pattern of patients that enter the hospital through the emergency ward (emergency room or department). The ED arrival module 132 is in communication with ED configuration file 144, which embodies constraints regarding the emergency department and its operations, and user configurable parameters for customizing ED data. The ED algorithm creates the pattern of arrivals of patients to the emergency department using a base waveform (base signal). The base waveform and its parameters are specified based on domain knowledge. The base waveform may include periodic functions (fixed trigonometric base waveforms), such as sine signals, cosine signals, square waves, and custom periodic functions (customized base waveforms). Alternatively, the base waveform may be defined by a custom pattern that is not periodic. The choice of fixed or customized base waveforms is based on observation of the required mathematical characteristics needed to describe patient arrivals in the emergency department, including hourly, daily, and monthly seasonality of arrivals, as well as noise (the ability to include irregularities in the pattern of arrivals). For example, periodic trigonometric functions, like sine and cosine, have very smooth forms, which allow continual rise and decline from specified peaks. However, the patern of arrivals of patients may be skewed within one period, resulting for example in an abrupt rise and slow decline within a period rather than a smooth and symmetric peak. A customized base waveform is needed in order to reflect this type of skewed patern in the synthetic data. Selection of the base waveform can be accomplished by user intuition or based on their specific objectives. Both the fixed and customized base waveforms require parameters that specify the period and amplitude of the waveform and the required noise of the base waveforms.

[0049] It is assumed that observations are possible to inform the user of which arrival paterns are realistic for the use-case, and thus qualitative observations of real emergency department admissions may be used as follows: First, arrival data in the ward is collected and observed over a predetermined period of time. Second, the user determines whether a periodic function exists in the arrival data. Third, when there is no periodic function, the user determines a customized periodic function that reflects the patern of the observed arrival data. Fourth, the observed periodic function or the customized periodic function is applied to generate the base waveform. The process applied by the ED arrival module 132 is described below with reference to Fig. 3A.

[0050] The DA arrival module 133 is configured to apply a DA algorithm that generates the arrival patern of patients who are directly placed on wards of the hospital. The DA arrival module 133 is in communication with DA configuration file 145, which embodies constraints regarding the direct admission operations, and user configurable parameters for customizing DA data. The DA algorithm creates the patern of arrivals of patients into the various different wards using a base waveform. Again, the base waveform and its parameters are specified based on domain knowledge. The base waveform may include periodic functions, such as sine signals, cosine signals, square waves, and custom periodic functions. Alternatively, the base waveform may be defined by a custom patern that is not periodic. Selection of the waveform can be accomplished by user intuition or based on their specific objectives. When observations are possible to inform the user of which paterns are realistic for their use-case, qualitative observations of real direct admissions may be used in the same manner as described above with regard to the ED admissions to generate the base waveform. The process applied by the DA arrival module 133 is described below with reference to Fig. 3B.

[0051] The TC arrival module 134 is configured to apply a TC algorithm that generates the arrival patern of patients who are transferred to wards of the hospital from other institutions. The TC arrival module 134 is in communication with TC configuration file 146, which embodies constraints regarding the direct admission operations, and user configurable parameters for customizing TC data. The TC algorithm captures the patern of arrivals of patients into the various different wards using a base waveform. The base waveform may include periodic functions, such as sine signals, cosine signals, square waves, and custom periodic functions. Alternatively, the base waveform may be defined by a custom patern that is not periodic. When observations are possible to inform the user of which paterns are realistic for their use-case, qualitative observations of real transfer center admissions may be used in the same manner as described above with regard to the ED admissions to generate the base waveform. The process applied by the TC arrival module 134 is described below with reference to Fig. 3C.

[0052] The SC arrival module 135 is configured to apply an SC algorithm that generates the arrival pattern (surgical schedule) of patients who are scheduled for surgeries in one or more surgical wards (operating rooms) of the hospital. The SC arrival module 135 is in communication with SC configuration file 147, which embodies constraints regarding the surgical operations, and user configurable parameters for customizing SC data. Unlike the other arrival modules discussed above, the SC arrival module 135 does not use a base waveform to generate arrival patterns. Instead, the SC algorithm generates a schedule based on surgical constraints, including one or more of specific operating rooms in the hospital, a number of beds in each operating room, and daily and hourly availability of each operating room for specific types of surgery. The process applied by the SC arrival module 135 is described below with reference to Fig. 3D.

[0053] As explained above, the ED arrival module 132, the DA arrival module 133, and the TC arrival module 134 use base waveforms comprising periodic functions or custom patterns to capture the corresponding patient arrival patterns. Non-limiting examples of configurable parameters of the corresponding ED configuration file 144, DA configuration file 145, and TC configuration file 146 that may be populated by the user are shown in Table 2, below. Of course, additional or fewer base waveform based configurable parameters, as well as different configurable parameters, may be incorporated without departing from the scope of the present teachings.

[0054] Table 2

[0055] In comparison, the SC arrival module 135 uses a schedule to capture the corresponding patient arrival pattern. Non-limiting examples of configurable parameters of the corresponding SC configuration file 147 that may be populated by the user are shown in Table 3, below. Of course, additional or fewer schedule based configurable parameters, as well as different configurable parameters, may be incorporated without departing from the scope of the present teachings.

[0056] Table 3

[0057] Analytics module 136 is configured to apply currently known or later developed Al analytics algorithms to the synthetic data (integrated patient trajectory) output by the synthetic data generation module 131. The Al analytics algorithms provide realistic situational simulations based on the realistic synthetic data, which improves patient care and treatment by enabling accurate staff planning, resource allocation, remediation strategy determination to alleviate overcrowding of the hospital, and the like. The Al analytics algorithms may include previously trained machine learning models, for example, implemented as neural network, such as an artificial neural network (ANN), a convolutional neural network (CNN), a recurrent neural network (RNN), or a U-net model, for example. The realistic synthetic data provided by the integrated patient trajectory improves functionality of the Al analytics algorithms, which in turn output more accurate and reliable results. These Al analytics algorithms are used to determine patient level properties, such as length of stay, hospital transitions, ward placement, and general hospital stay characteristics that would impact operational decisions, for example.

[0058] Clinical enhancement module 137 is configured to enhance the synthetic data output by the synthetic data generation module 131 using clinical data from selected actual clinical cases, where the clinical data is de-anonymized to provide privacy protection of the patients associated with the clinical data. The clinical enhancement module 137 accesses a patent database (e.g., database 112) and selects actual clinical cases that fall within certain parameters of the synthetic data. For example, if the synthetic data output by the synthetic data generation module 131 is used to predict surgical outcomes of a particular type of surgery, actual clinical data of patients who have undergone that type of surgery may be selected. The clinical enhancement module 137 de-anonymizes the selected clinical data by removing all identifying data that may compromise the patients’ identities, such as names, surgery dates, attending physicians, and the like. The clinical enhancement module 137 combines the synthetic data with the deanonymized clinical data to generate enhanced synthetic data, including the selected de-anonymized clinical data, thereby maintaining privacy protection. The actual clinical data may be taken from various different hospitals and / or various different years. This allows the user to build a synthetic dataset according to the operational constraints and parameters that are enhanced with actual clinical data, but also provide extra privacy protection by combining patient data that is unrelated in geography and time.

[0059] As another example, the synthetic data generation module 131 generates operational synthetic data that specifies that the average LOS of patients in the ICU ward is three days, where the maximum LOS is five days and the minimum LOS is one day. The clinical enhancement module 137 may then search a clinical data set, such as Medical Information Mart for Intensive Care (MIMIC)-III clinical database or electronic intensive care unit (eICU), for example, for actual clinical data of cases that meet the same LOS criteria. The clinical enhancement module 137 then associates the actual clinical data with the simulated patients from the synthetic data.

[0060] Fig. 2 is a flow diagram of a method of generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, according to a representative embodiment. Fig. 2 may be implemented by the processor 120 of the workstation 105, executing instructions stored in the memory 130, for example, as discussed above.

[0061] Referring to Fig. 2, a hospital configuration file is populated in block S211 by specifying hospital parameters to provide data specific to the hospital and by specifying simulation criteria. The hospital specific data may include patient data, such as specific patient populations and needed services like a focus on cancer patients via a cancer center, for example. The hospital specific data further includes ward capacity data indicating the capacity of each ward in the hospital to receive patients, and ward occupancy data indicating the occupancy of each ward in the hospital by patients at particular times within the simulation. The simulation criteria may include at least a time length of the simulation.

[0062] In block S212, a transition probabilities configuration file is populated by specifying transition probabilities specific to the wards and patients in the wards moving to other wards over the time length of the simulation. The transition probabilities configuration file includes configurable parameters that identify all the hospital wards and associated probabilities of the patients transitioning from these wards to other hospital wards, respectively. For surgical cases, in particular, the transition probabilities may be further defined based on the types of surgery. At least in some embodiments, the transition probabilities from one hospital ward (e.g., inpatient unit) to other hospital ward can be computed using the historical patient transition counts or based on the expert knowledge input based on continued humanmachine interaction, e.g. asking for expert input and adapting the probabilities based on expert input, then having another iteration, etc. For instance, the Expert can input that e.g., ED to Medical ward transitions are only c.a. in 20% of the cases from the ED patients, which can be inputted and given a certain weight (e.g., low, medium, high), so that the system understands the impact of this particular expert input. These transition number could be maintained in a configuration file, which could be used for changing the input on the system.

[0063] In block S213, a LOS configuration file is populated by generating simulated lengths of stays of the patients, respectively. The lengths of stay may be generated according to different processes, such as statistical probability distributions, for example.

[0064] In block S214, multiple arrival configuration files are populated, where the arrival configuration files respectively correspond to multiple arrival modules for simulating different arrival scenarios of patients entering the hospital. As discussed above, the arrival configuration files may include ED configuration file 144, DA configuration file 145, TC configuration file 146, and SC configuration file 147 that respectively correspond to ED arrival module 132, DA arrival module 133, TC arrival module 134, and SC arrival module 135. The arrival configuration files are populated by specifying arrival parameters for the arrival modules, respectively. In addition to the populated parameters, each arrival module includes at least one corresponding constraint that is dictated by limitations of the hospital and / or the wards to which they apply. Each arrival module is configured to generate a base waveform (or base signal) that captures corresponding arrival patterns based on the at least one corresponding constraint and the configurable parameters. Alternatively, or in addition, one or more arrival modules of the multiple arrival modules is configured to generate a schedule based on the at least one corresponding constraint and the configurable parameters.

[0065] Block S215 indicates processes for generating patient trajectories for the arrival modules, respectively. Each of the patient trajectories is generated based on the base waveform or the schedule from the respective arrival configuration file, as well as the data specific to the hospital from the hospital configuration file. When one or both of the transition probability configuration file and the LOS configuration file are populated in steps S213 and S214, then each of the patient trajectories may be generated further based on the transition probabilities specific to the wards and the patient types and / or the simulated lengths of stays of the patients, respectively. The processes for generating the patient trajectories for the arrival modules are discussed below with reference to Figs. 3A-3D.

[0066] Fig. 3A is a flow diagram of a method of generating a patient trajectory for simulating emergency department admissions, according to a representative embodiment. FIG. 3A may be implemented by the processor 120, for example, executing instructions of the ED arrival module 132 stored in the memory 130 to apply an ED algorithm for generating the arrival pattern of patients who enter the hospital through the emergency room, as discussed above. Referring to Fig. 3A, in block S311, an ED configuration file is populated by specifying ED configurable parameters to provide data specific to the emergency department. The ED configuration file may be populated by the user assigning values to various fields, as discussed above with reference to Table 2. In block S312, a base waveform of an ED arrival pattern of the hourly arrival count is determined by the user based on the configurable parameters in the ED configuration file. The base waveform of the ED arrival pattern is determined from a set of mathematical characteristics used to define a trigonometric periodic function or a customized periodic function, as discussed above. Determining the base waveform includes adjusting amplitude as well as periodicity. In block S313, occupancy of the emergency department by patients is retrieved from the hospital configuration file 141. In block S314, the hourly arrival count of patients entering the emergency department is updated using the base waveform and the occupancy information. In block S315, an ED patient trajectory is generated based on the updated hourly arrival count from the base waveform. The ED patient trajectory is returned to Fig. 2.

[0067] Fig. 3B is a flow diagram of a method of generating a patient trajectory for simulating direct admissions, according to a representative embodiment. Fig. 3B may be implemented by the processor 120, for example, executing instructions of the DA arrival module 133 to apply a DA algorithm for generating the arrival pattern of patients who are placed directly on wards of the hospital by direct admission, as discussed above.

[0068] Referring to Fig. 3B, in block S321, a DA configuration file is populated by specifying DA configurable parameters to provide data specific to the direct admissions. The DA configuration file may be populated by the user assigning values to various fields, as discussed above with reference to Table 2. In block S322, a base waveform of a DA arrival pattern of the hourly arrival count is determined by the user based on the configurable parameters in the DA configuration file. Generally, the base waveform of the DA arrival pattern is determined in the same manner as the base waveform of the ED arrival pattern discussed above, although the parameter ranges of the respective base waveforms are different, which means the resulting waveforms are different. In block S323, an initial ward list is retrieved from the hospital configuration file 141. The initial ward list provides a list of wards in the hospital and a list of patients initially present in each of the wards at the beginning of the simulation. In block S324, the occupancy of each ward by patients is checked based on occupancy data retrieved from the hospital configuration file 141. In block S325, the initial ward list and the number of patients in each ward are updated using the base waveform according to the hourly arrival count of patients entering each ward. In block S326, a DA patient trajectory is generated based on the updated ward list and the updated number of patients for the wards from the base waveform. The DA patient trajectory is returned to Fig. 2.

[0069] Fig. 3C is a flow diagram of a method of generating a patient trajectory for simulating transfer center admissions, according to a representative embodiment. Fig. 3C may be implemented by the processor 120, for example, executing instructions of the TC arrival module 134 to apply a TC algorithm for generating the arrival pattern of patients who are transferred from another institution to a ward of the hospital, as discussed above.

[0070] Referring to Fig. 3C, in block S331, a TC configuration file is populated by specifying TC configurable parameters to provide data specific to the transfer center. The TC configuration file may be populated by the user assigning values to various fields, as discussed above with reference to Table 2. In block S332, a base waveform of a TC arrival pattern of the number of transfer calls is determined by the user based on the configurable parameters in the TC configuration file. Generally, the base waveform of the TC arrival pattern is determined in the same manner as the base waveform of the ED arrival pattern discussed above, although the parameter ranges of the respective base waveforms are different, which means the resulting waveforms are different. In block S333, an initial ward list and a severity level list are retrieved from the hospital configuration file 141. The initial ward list provides list of patients initially present in each of the wards at the beginning of the simulation, and the severity level list includes the level of severity of each patient’s condition on the corresponding ward. The severity level may be provided using a predetermined scale, for example. In block S334, the number of transfer call of patients to be transferred to each ward of the hospital from other institutions is updated using the base waveform according to the TC arrival pattern of patients to be transferred to each ward. In block S335, a transfer queue is generated for each ward for admission of the transfer cases to that ward based on the list of patients initially present, the severity level of the patients, and the updated number of transfer calls. The order of patients in the transfer queue may be determined by weighting factors such as the original order of transfer requests of the patients and the comparative severity levels of the patients. At least in some embodiments, the severity level list refers to the patients in the transfer center and can be used to prioritize the patients placed into a hospital ward.

[0071] Meanwhile, in block S336, reserve capacity data indicating the reserve capacity of each ward in the hospital is retrieved from the hospital configuration file 141, and in block S337, the occupancy of each ward is checked based on the retrieved reserve capacity data. In block S338, the patients on the list of transfer patients for each ward are de-queued from the transfer queue based on the occupancy of that ward. In block S339, the initial ward list and number of patients being transferred to each ward are updated based on de-queuing the transfer patients. In block S340, a TC patient trajectory is generated based on the updated ward list and the updated number of transfer patients for the wards to the base waveform. The TC patient trajectory is returned to Fig. 2.

[0072] Fig. 3D is a flow diagram of a method of generating a patient trajectory for simulating surgical center operations, according to a representative embodiment. Fig. 3D may be implemented by the processor 120, for example, executing instructions of the SC arrival module 135 to apply an SC algorithm for generating the arrival pattern of patients who are scheduled for surgeries in surgical wards of the hospital, as discussed above.

[0073] Referring to Fig. 3D, in blocks S341 and S342, case data and session data are created from data retrieved from the SC configuration file 147, respectively. The case data specifies the types of different surgical cases considered, while the session data specifies how many surgical sessions are allowed for each case in a given time increment, e.g., a day or a week. In block S343, a surgical schedule is created for the surgeries based on the case data and the session data. The surgical schedule includes placement of case specific surgical sessions at fixed times, e.g., an orthopedic surgery at 1 lam in surgical room 2.

[0074] In block S344, it is determined whether the scheduled start time of each surgery falls within a predetermined time period, which may be set by the start date and time parameters of the hospital configuration file. For example, it may be determined whether the scheduled start time is within a one hour window from the current time (current time < start time < current time + 1 hour). When the scheduled start time is not within the predetermined time period (block S344: No), the process repeats as the current time changes. When the scheduled start time is within the predetermined time period (block S344: Yes), the process proceeds to block S345, in which initial ward information for surgery wards is retrieved from the hospital configuration file, including ward identification and occupancy and types of surgery that may be performed in the wards. In block S346, information regarding all of the surgeries is extracted from the surgical schedule created in block S343 and reconciled with the initial ward information for the surgeries. In block S347, an SC patient trajectory is generated using the retrieved surgery information, and returned to Fig. 2.

[0075] Referring again to Fig. 2, once the ED patient trajectory, the DA patient trajectory, the TD patient trajectory, and the SC patient trajectory, have been generated according to the corresponding algorithms in Figs. 3A-3D, they are integrated with one another in block S216 to provide an integrated patient trajectory. In an embodiment, an integrated patient trajectory algorithm inputs the ED patient trajectory, the DA patient trajectory, the TD patient trajectory, and the SC patient trajectory, and outputs the integrated patient trajectory. The integrated patient trajectory algorithm may be a rule based algorithm, for example. The integrated patient trajectory includes the synthetic data specific to the patient flow in the hospital. In various embodiments, fewer than all four of the patient trajectories may be integrated to provide the integrated patient trajectory, without departing from the scope of the present teachings.

[0076] In block S217, the integrated patient trajectory is applied to an Al analytics algorithm in order to enable realistic situational simulations of patient pathways through the hospital. The realistic simulations enable a number of predictions that are useful for the treatment of patients and administration of the hospital, including staff planning, resource allocation, and simulated remediation strategies to alleviate overcrowding of the hospital. One example could include simulation of the hospital census in e.g., the fall season. In this non-limiting embodiment, based on historical data and current occupancy, the simulation could predict increases in bed occupancy due to seasonal flu. The hospital administration can use the predicted occupancy for staff planning to insure the necessary number of nurses are available.

[0077] The realistic simulation may include a predictive algorithm that is dependent on historical data for calibration, for example, where the historical data may not exist or may not be otherwise available. The integrated patient trajectory is able to synthesize realistic data that can be added to or used by the predictive algorithm for calibration. Because the synthesized data is more realistic than conventional synthesized data and more voluminous than the available actual data, the functionality and results of the predictive algorithm are greatly improved. In some embodiments, the advantage is achieved that the synthetic data generated by the system is more realistic and accurate than the “conventional” synthesized data, due to the fact that the data is specific to the target hospital and the patient population that has historically visited that target hospital. In some embodiments, the volume can be adjusted to meet the needs of the algorithm training, which allows for the improved training and tuning of the algorithm to make predictions on the target population.

[0078] For example, a large urban hospital with various departments, including emergency, surgery, radiology, and inpatient units, faces challenges related to patient flow, resource allocation, and efficiency. The hospital administration wants to improve patient care, reduce waiting times, optimize resource utilization, and enhance overall operational efficiency. In this case, an Al analytics algorithm may be a previously trained simulation model configured to simulate patient arrivals at the emergency department and test different triage strategies based on the integrated patient trajectory. For example, the simulation model may generate patient schedules that minimize bottlenecks and maximize resource utilization (e.g., scheduling of surgeries). The simulation model may also aid in planning ward level capacity and performing what-if scenarios.

[0079] At least in some embodiments, the method further comprises populating e.g., a transition probability configuration file (or any other suitable file, database, file in a database, etc.) by specifying transition probabilities specific to the wards and patient types for patients moving between the wards over the time length of the simulation and populating a length of stay, LOS, configuration file by generating simulated lengths of stays of the patients. Generating the patient trajectory for the at least one arrival module of the plurality of arrival modules may be further based on the transition probabilities and the simulated lengths of stays of the patients.

[0080] At least in some embodiments, the method further comprises determining the lengths of stays of the patients, the said length being generated based on a statistical probability distribution comprising at least one of: a fixed value distribution, a random lognormal distribution, or an exponential distribution.

[0081] At least in some embodiments, the method further comprises analyzing base waveform based on a predetermined periodic function and / or is customizable.

[0082] At least in some embodiments, the method further comprises selecting actual clinical cases that fall within the plurality of arrival parameters and combining the synthetic data with a de-anonymized clinical data from the selected actual clinical cases to generate enhanced synthetic data. At least in some embodiments, the method further comprises populating via e.g., a graphical user interface, GUI, a plurality of hospital parameters and the plurality of arrival parameters. Here arrival parameters may refers to the mathematical parameters used to describe the arrival pattern of the patients to the hospital and the corresponding arrival rates.

[0083] At least in some embodiments, the plurality of arrival modules comprise an emergency department module configured to generate an emergency arrival pattern of patients that enter the hospital through an emergency room, a direct admission module configured to generate a direct arrival pattern of patients that are placed directly in wards of the hospital by direct admission, and a transfer center module configured to generate a transfer arrival pattern of patients that are transferred from other institutions, and wherein the emergency department module, the direct admissions module, and the transfer center module use corresponding base waveforms to capture the emergency arrival pattern, the direct arrival pattern, and the transfer arrival pattern, respectively.

[0084] At least in some embodiments, the plurality of arrival modules further comprise a surgical case module configured to generate a surgery schedule for a simulation based on surgical constraints and the arrival parameters for the surgical case module.

[0085] At least in some embodiments, the surgical constraints comprise one or more of: operating rooms in the hospital, a number of beds in each operating room, and daily and hourly availability of each operating room for different types of surgery.

[0086] Although the present specification describes components and functions that may be implemented in particular embodiments with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. Such standards are periodically superseded by more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions are considered equivalents thereof.

[0087] The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of the various embodiments. The illustrations are not intended to serve as a complete description of all of the elements and features of the disclosure described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Additionally, the illustrations are merely representational and may not be drawn to scale. Certain proportions within the illustrations may be exaggerated, while other proportions may be minimized. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.

[0088] One or more embodiments of the disclosure may be referred to herein, individually and / or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any particular invention or inventive concept. Moreover, although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the description.

[0089] The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b) and is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, various features may be grouped together or described in a single embodiment for the purpose of streamlining the disclosure. This disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may be directed to less than all of the features of any of the disclosed embodiments. Thus, the following claims are incorporated into the Detailed Description, with each claim standing on its own as defining separately claimed subject matter.

[0090] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to practice the concepts described in the present disclosure. As such, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

[0091] Aspects of the disclosure may be supported by various information technology (IT) backends, including either or both local architectures, either as monoliths, networked, or a combination thereof, and hosted architectures, such as a software as a service (SaaS), platform as a service (PaaS), and / or infrastructure as a service (laaS), or the like. In an example, a supporting infrastructure includes multiple interconnected layers respectively hosting, as an abstraction, various IT process, service, account, and other management components.

[0092] The layers of the supporting infrastructure may be divided into, for example and without imputing limitation, a Hosting Layer (HL), a Development Layer (DL), a Platform Layer (PL), and a Cloud Provision Layer (CPL). Each layer is generally structured to support a designated aspect of the IT backend supporting software product offerings and is made of various components that each may include any or all of libraries, functions, application programming interfaces (APIs), data stores, and more. The HL includes hosting management utilities enabling management of accounts related to the CPL, either directly by an end user or by a software product IT management. The DL largely mirrors the HL in that it includes hosting management utilities; however, the DL is generally structured to maintain a division from software product offerings provided to end users and serves as an environment for testing and development without risking impacting end user use of software products provided over the IT backend. The CPL is a foundational layer “upon” which the HL, DL, and PL operate and with which components of each of the other layers interact to varying degrees. The CPL provides direct access to remote server infrastructure supporting the IT backend. The PL includes a number of components for providing platform support for software products. Platform support may include functions such as orchestration, layer integrations, software product operational functions, data repository access and / or management, and more.

[0093] The HL and DL may have largely similar structure such that the DL supports iteration on software products offered to customers over the HL. Both of the HL and DL include account activation and management components. Accounts managed on the HL may be limited in allowed access privileges for various components on the PL and / or CPL. Accounts may be linked to singular software products and / or specific customers.

[0094] The CPL includes various obfuscated processes for performing infrastructural services supporting the layers which operate upon it. In some examples, these obfuscated processes may include virtual server instantiation, hardware (e.g., physical server) orchestration and management, redundancy and backup operations, security and logging, routing operations, and more. Nevertheless, the CPL typically includes multiple sub-layers of abstraction, including at least an interfacing sub-layer for communicating with external layers, such as those herein described.

[0095] The PL is the primary location of the hosted product and service offerings, as well the processes that support these offerings. Among the various processes and modules that reside in, or originate from, the PL, orchestration and management modules typically interconnect the PL and the CPL. Where the HL and / or DL provide immediate interfaces to downstream users for various products and / or services, the PL contains the primary operational elements enabling and providing the products and / or services to users.

[0096] It is to be understood that any of the previous steps described in relation to embodiments and / or training steps described above can be performed by a specific-purpose computer system or general-purpose computer system, or a computer-readable medium, or data carrier system configured to carry out any of the steps described previously. The computer system can include a set of software instructions that can be executed to cause the computer system to perform any of the methods or computer-based functions disclosed herein. The computer system may operate as a standalone device or may be connected, for example using a network, to other computer systems or peripheral devices. In embodiments, a computer system performs logical processing based on digital signals received via an analogue-to-digital converter.

[0097] Some portions of the description are presented in terms of symbolic representations of operations on non-transient signals stored within a computer memory. These descriptions and representations are used by those skilled in the data processing arts to convey the substance of their work most effectively to others skilled in the art. Such operations typically require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times to refer to certain arrangements of steps requiring physical manipulation of physical quantities as modules or code devices, without loss of generality.

[0098] However, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage devices. Portions of the present disclosure include processes and instructions that may be embodied in software, firmware, or hardware, and when embodied in software, may be downloaded to reside on and be operated from different platforms used by a variety of operating systems.

[0099] In a networked deployment, the computer system operates in the capacity of a server, or as a client user computer in a server-client user network environment, or as a peer computer system in a peer-to-peer or distributed network environment. The computer system can also be implemented as or incorporated into various devices, such as a server or another type of computer such as a workstation that includes a controller, a stationary computer, a mobile computer, a personal computer (PC), a laptop computer, a tablet computer, or any other machine capable of executing a set of software instructions sequentially or non-sequentially that specify actions to be taken by that machine. The computer system can be incorporated as an integrated system part of a larger system that includes additional devices. In an embodiment, the computer system can be implemented using electronic devices that provide voice, video, or data communication possibilities. Further, while the computer system is illustrated in the singular, the term “system” shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set or multiple sets, of software instructions to perform one or more computer functions.

[0100] The computer system may also include a processor. The processor executes instructions to implement some, or all aspects of methods and processes described herein. The processor may be a general-purpose processor or may be part of an application specific integrated circuit (ASIC). The processor may also be a microprocessor, a microcomputer, a processor chip, a controller, a microcontroller, a digital signal processor (DSP), a state machine, or a programmable logic device, a logical circuit, including a programmable gate array (PGA), such as a field programmable gate array (FPGA), or another type of circuit that includes discrete gate and / or transistor logic. The processor may be a central processing unit (CPU), a graphics processing unit (GPU), or both. Additionally, any processor described herein may include multiple processors, parallel processors, or both. Multiple processors may be included in, or coupled to, a single device or multiple devices. The processor can include one or more internal levels of cache, and a bus controller or bus interface unit to direct interaction with a bus. The term “processor” as used herein encompasses an electronic component able to execute a program or machine executable instruction. References to a computing device comprising “a processor” should be interpreted to include more than one processor or processing core, as in a multi-core processor. A processor may also refer to a collection of processors within a single computer system or distributed among multiple computer systems. The term computing device should also be interpreted to include a collection, or network, of computing devices each including a processor or processors. Programs have software instructions performed by one or multiple processors that may be within the same computing device or which may be distributed across multiple computing devices. Further, the software instructions, when executed by the processor, perform one or more steps of the methods and processes as described herein.

[0101] The computer system further includes a main memory and a static memory, where memories in the computer system communicate with each other and the processor via a bus. Either or both main memory and the static memory may be considered representative examples of the memory of the controller, and store instructions used to implement some, or all aspects of methods and processes described herein. Memories described herein are tangible storage mediums for storing data and executable software instructions and are non-transitory during the time software instructions are stored therein. The main memory and the static memory are articles of manufacture and / or machine components. The main memory and the static memory are computer-readable mediums from which data and executable software instructions can be read by a computer (or e.g., the processor). Each of the main memory and the static memory may be implemented as one or more of random access memory (RAM), read only memory (ROM), flash memory, electrically programmable read only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, tape, compact disk read only memory (CD-ROM (Compact Disk - Read Only Memory)), digital versatile disk (DVD), floppy disk, Blu-ray disk, or any other form of storage medium known in the art. The memories may be volatile or non-volatile, secure and / or encrypted, unsecure and / or unencrypted.

[0102] The computer system can further include a communications interface by way of which the computer system can connect to networks and receive data useful in executing the methods and system set out herein as well as transmitting information to other devices. The computer system further includes a video display unit as an output device by which information can be output, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, or a cathode ray tube (CRT), for example. Additionally, the computer system includes an input device, such as a keyboard / virtual keyboard or touch-sensitive input screen or speech input with speech recognition, and a cursor control device, such as a mouse or touch-sensitive input screen or pad. The computer system also optionally includes a disk drive unit, a signal generation device, such as a speaker or remote control, and / or a network interface device.

[0103] In accordance with various embodiments of the present disclosure, the methods described herein may be implemented using a hardware computer system that executes software programs. Further, in an exemplary, non-limited embodiment, implementations can include distributed processing, component / object distributed processing, and parallel processing. Virtual computer system processing may implement one or more of the methods or functionalities as described herein, and a processor described herein may be used to support a virtual processing environment.

[0104] The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of the various embodiments. The illustrations are not intended to fully describe all the elements and features of the disclosure described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Additionally, the illustrations are merely representational and may not be drawn to scale. Certain proportions within the illustrations may be exaggerated, while other proportions may be minimized. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.

[0105] Although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art.

Claims

CLAIMS:

1. A computer-implemented method of generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, the method comprising: populating a hospital configuration file by specifying a plurality of hospital parameters to provide data specific to the hospital, including at least one of: patient data, ward capacity data indicating capacity of at least one ward of a plurality of wards in the hospital, ward occupancy data indicating occupancy of at least one ward of the plurality of wards,, ward capacity data indicating capacity of wards in the hospital by specifying simulation criteria including at least a time length of the simulation and ward occupancy data indicating occupancy of the wards in the hospital; populating a plurality of arrival configuration files by specifying a plurality of arrival parameters for a plurality of arrival modules, wherein the plurality of arrival modules comprise at least one constraint, the plurality of arrival modules configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint, or configured to generate a schedule based on the at least one corresponding constraint; generating at least one patient trajectory for at least one arrival module of the plurality of arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file; integrating the at least one patient trajectory from the plurality of arrival modules to provide an integrated patient trajectory comprising synthetic data specific to the patient flow in the hospital; and applying an analytics algorithm to the integrated patient trajectory for providing realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies in a hospital workflow.

2. The method of claim 1 further comprising: populating a transition probability configuration file by specifying transition probabilities specific to the wards and patient types for patients moving between the wards over the time length of the simulation; and populating a length of stay, LOS, configuration file by generating simulated lengths of stays of the patients, wherein generating the patient trajectory for the at least one arrival module of the plurality of arrival modules is further based on the transition probabilities and the simulated lengths of stays of the patients.

3. The method of claim 2, wherein the lengths of stays of the patients are generated based on a statistical probability distribution comprising at least one of: a fixed value distribution, a random lognormal distribution, or an exponential distribution.

4. The method of any one of the preceding claims, wherein the base waveform is based on a predetermined periodic function and / or is customizable.

5. The method of any one of the preceding claims further comprising: selecting actual clinical cases that fall within the plurality of arrival parameters; and combining the synthetic data with a de-anonymized clinical data from the selected actual clinical cases to generate enhanced synthetic data.

6. The method of any one of the preceding claims, wherein the plurality of hospital parameters and the plurality of arrival parameters are populated via a graphical user interface.

7. The method of any one of the preceding claims, wherein the plurality of arrival modules comprise an emergency department module configured to generate an emergency arrival pattern of patients that enter the hospital through an emergency room, a direct admission module configured to generate a direct arrival pattern of patients that are placed directly in wards of the hospital by direct admission, and a transfer center module configured to generate a transfer arrival pattern of patients that are transferred from other institutions, and wherein the emergency department module, the direct admissions module, and the transfer center module use corresponding base waveforms to capture the emergency arrival pattern, the direct arrival pattern, and the transfer arrival pattern, respectively.

8. The method of claim 7, wherein the plurality of arrival modules further comprise a surgical case module configured to generate a surgery schedule for a simulation based on surgical constraints and the arrival parameters for the surgical case module.

9. The method of claim 8, wherein the surgical constraints comprise one or more of: operating rooms in the hospital, a number of beds in each operating room, and daily and hourly availability of each operating room for different types of surgery.

10. A non-transitory computer readable medium storing instructions for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, that when executed by a processor, cause the processor to:populate a hospital configuration file by specifying a plurality of hospital parameters to provide data specific to the hospital, including patient data, ward capacity data indicating capacity of each ward of a plurality of wards in the hospital, and ward occupancy data indicating occupancy of each ward of the plurality of wards, and by specifying simulation criteria including at least a time length of the simulation, ward capacity data indicating capacity of wards in the hospital, and ward occupancy data indicating occupancy of the wards in the hospital; populate a plurality of arrival configuration files by specifying a plurality of arrival parameters for a plurality of arrival modules, respectively, wherein each arrival module comprises at least one corresponding constraint, and is configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint or to generate a schedule based on the at least one corresponding constraint; generate a patient trajectory for each arrival module of the plurality of arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file; integrate the patient trajectories from the plurality of arrival modules to provide an integrated patient trajectory comprising synthetic data specific to the patient flow in the hospital; and apply the integrated patient trajectory to an analytics algorithm to enable realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies to alleviate overcrowding of the hospital.

11. The non-transitory computer readable medium of claim 11, wherein when executed, the instructions further cause the processor to: populate a transition probability configuration file by specifying transition probabilities specific to the wards and patient types for patients moving between the wards over the time length of the simulation; and populate a length of stay (LOS) configuration file by generating simulated lengths of stays of the patients, respectively, wherein the patient trajectory is generated for each arrival module of the plurality of arrival modules is further based on the transition probabilities and the simulated lengths of stays of the patients.

12. The non-transitory computer readable medium of claim 11, wherein the lengths of stays of the patients are generated based on a statistical probability distribution comprising one of a fixed value distribution, a random lognormal distribution, or an exponential distribution.

13. The non-transitory computer readable medium of claim 10, wherein each base waveform is based on a predetermined periodic function and / or is customizable.

14. The non-transitory computer readable medium of claim 10, wherein when executed, the instructions further cause the processor to: select actual clinical cases that fall within the plurality of arrival parameters; and combine the synthetic data with de-anonymized clinical data from the selected actual clinical cases to generate enhanced synthetic data including clinical data and privacy protection.

15. The non-transitory computer readable medium, wherein the plurality of hospital parameters and the plurality of arrival parameters are populated via a graphical user interface.

16. The non-transitory computer readable medium of claim 10, wherein the plurality of arrival modules comprise an emergency department module configured to generate an emergency arrival pattern of patients that enter the hospital through an emergency room, a direct admission module configured to generate a direct arrival pattern of patients that are placed directly on wards of the hospital by direct admission, and a transfer center module configured to generate a transfer arrival pattern of patients that are transferred from other institutions, and wherein the emergency department module, the direct admissions module, and the transfer center module use corresponding base waveforms to capture the emergency arrival pattern, the direct arrival pattern, and the transfer arrival pattern, respectively.

17. The non-transitory computer readable medium of claim 16, wherein the plurality of arrival modules further comprise a surgical case module configured to generate a surgery schedule for a simulation based on surgical constraints and the arrival parameters for the surgical case module.

18. The non-transitory computer readable medium of claim 17, wherein the surgical constraints comprise one or more of operating rooms in the hospital, a number of beds in each operating room, and daily and hourly availability of each operating room for different types of surgery.

19. A system for generating synthetic data pertaining to occupancy and flow of patients in a hospital to enable simulation of patient flow within the hospital, the system comprising: a processor; a user interface configured to enable interaction between a user and the processor; and a memory connected to the processor and storing instructions that, when executed by the processor, cause the processor to: populate a hospital configuration file by specifying a plurality of hospital parameters to provide data specific to the hospital, including patient data, ward capacity data indicating capacity of each ward of a plurality of wards in the hospital, and ward occupancy data indicating occupancy of each wardof the plurality of wards, and by specifying simulation criteria including at least a time length of the simulation, ward capacity data indicating capacity of wards in the hospital, and ward occupancy data indicating occupancy of the wards in the hospital populate a plurality of arrival configuration files by specifying a plurality of arrival parameters for a plurality of arrival modules, respectively, wherein each arrival module comprises at least one corresponding constraint, and is configured to generate a base waveform to capture corresponding arrival patterns based on the at least one corresponding constraint or to generate a schedule based on the at least one corresponding constraint; generate a patient trajectory for each arrival module of the plurality of arrival modules based on the base waveform or the schedule from the respective arrival configuration file, and based on the data specific to the hospital from the hospital configuration file; integrate the patient trajectories from the plurality of arrival modules to provide an integrated patient trajectory comprising synthetic data specific to the patient flow in the hospital; and apply the integrated patient trajectory to an analytics algorithm to enable realistic situational simulations for enabling staff planning, resource allocation, and / or simulated remediation strategies to alleviate overcrowding of the hospital.

20. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any one of claims 1-9.

Images