A healthcare enterprise, such as a hospital, may utilize resources to deliver healthcare to patients. For example, a hospital may have a limited number of hospital beds that can be assigned to patients. As a result, resource and patient flow management may be an important responsibility of a healthcare provider. In some cases, a balance between inpatient bed capacity/staffing levels and current/expected patient demand may need to be maintained across a period of time (e.g., through the next 24 hours). To help maintain such a balance, a healthcare provider may re-target patient placements and/or open or close healthcare units and beds based on existing and upcoming capacity and demand.
Failing to properly manage resource and patient flow may result in substantial admission waits (e.g., “boarding” patients in an emergency department) and reduce safety due to imbalances between nurse staffing and current inpatient census (often as a result of unanticipated variability in patient flow). Moreover, failing to manage patient bed occupancy may result in higher overall medical costs by increasing the average duration of inpatient stays, causing unnecessary ambulance diversions, etc.
Typically, a healthcare provider focuses on quantifying current conditions and planning for deterministic future events. In many cases, however, a throughput crisis may not be fully appreciated until after the consequences have affected the facility. At many facilities operational success depends on a few select individuals who attempt to track patient flow through the entire organization and “bed huddle” meetings to assess daily capacity needs. For example, bed huddle meetings (usually held in the morning and in the late afternoon) may let managers with operational decisioning responsibilities in key departments/units meet in person and provide the current census and anticipated patient admissions, discharges, and transfers. A net bed demand may be estimated based on the starting occupancy and anticipated inflows and outflows for each unit, and then be further adjusted based on the staff availability. Such an approach, however, is manually intensive and depends on each person's judgment. Furthermore, it may be difficult to predict potential bottlenecks and there is little ability to assess the outcomes that may result if certain actions were taken to avoid potential problems proactively.
It would therefore be desirable to provide systems and methods to facilitate accurate resource and patient flow management in an automated, efficient, and consistent manner.
A healthcare enterprise, such as a hospital, may utilize resources to deliver healthcare to patients. For example, a hospital may have a limited number of hospital beds that can be assigned to patients. As a result, resource and patient flow management may be an important responsibility of a healthcare provider and it would therefore be desirable to provide systems and methods to facilitate accurate resource and patient flow management in an automated, efficient, and consistent manner.
According to some embodiments, an “automated” healthcare enterprise simulation model 150 may facilitate resource and patient flow management using a Graphical User Interface (“GUI”) 152. As used herein, the term “automated” may refer to, for example, actions that can be performed with little or no human intervention. The healthcare enterprise simulation model may use the resource snapshot data and generate a predicted future state of resources that can be provided to healthcare professionals 160, such as nurses or managers. According to some embodiments, an engine 154 may facilitate the generation of such predictions. The healthcare enterprise simulation model 150 might also transmit information to an external automated system 170, such as a report generator, workflow application, email notification system, pager application, Short Messaging System (“SMS”) gateway, or the like.
As used herein, devices, including those associated with the healthcare enterprise simulation model 150 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), a Wireless Application Protocol (WAP) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (IP) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks. Moreover, embodiments may be implemented in a “cloud” based environment such that at least some of the processing is performed by a remote system.
The healthcare enterprise simulation model 150 may store information into and/or retrieve information from the historical information database 140. The historical information database 140 may be locally stored or reside remote from the healthcare enterprise simulation model 150. Although a single healthcare enterprise simulation model 150 is shown in
At S210, snapshot data is received indicative of a current state of resources that deliver healthcare to a plurality of patients associated with a healthcare enterprise. According to some embodiments, the method 200 of
At S220, the received snapshot data is automatically used to initialize a healthcare enterprise simulation model. Note that the model may have been previously configured based on the structure of the healthcare enterprise. For example, the configuration might involve defining a plurality of treatment “units” of the healthcare enterprise simulation model and defining patient flow characteristics into, within, between, and out of the plurality of treatment units. As used herein, the phrase “treatment unit” might refer to real or virtual hospital locations having specific, limited patient capacities; for example, an emergency department, an outpatient unit, a holding room, an operating room, a recovery room, a cardiac treatment unit, a physical therapy unit, an X-ray and MRI unit, and/or an intensive care unit.
At S230, the healthcare enterprise simulation model is executed to generate a predicted future state of the resources at a predetermined point in time. For example, the model might predict a number of available patient beds over the next 24 hours. According to some embodiments, the model generates a plurality of predicted future states of the resources, each associated with a different predetermined point in time. According to some embodiments, the model also receives scheduled future events and the predicted future state of the resources is further based on the scheduled future events (e.g., the number and type of surgeries scheduled for a particular day). Note that the predicted future state of the resources may also be based on predicted future events (e.g., based at least in part historical information of the healthcare enterprise).
According to some embodiments, a potential patient flow bottleneck may be automatically detected by the healthcare enterprise simulation model. For example, the model might detect that too many patients are going to be assigned to a particular medical unit. In this case, a warning may output when the potential patient flow bottleneck is detected and/or a mitigation recommendation may be automatically generated.
According to some embodiments, the predicted future state of the resources at the predetermined point in time may be automatically compared with the actual state of the resources at the predetermined point in time. For example, a predicted number of available patient beds a 5:00 PM might be compared to the number of beds that were actually available at that time. Moreover, based on a result of said comparison, the healthcare enterprise simulation model might automatically adjusted (e.g., to improve the performance of the model).
According to some embodiments, the healthcare enterprise simulation model is parametrically driven and hot started based on periodic snapshots of the hospital state. Moreover, possible alternative future states of the hospital may be predicted for upcoming work shifts to provide early visibility into potential resource bottlenecks (e.g., bed shortages) and proactive feedback to decision makers regarding potential alternatives to avoid or minimize the impact of such bottlenecks. These mitigation alternatives may include, for example: the timely discharge or transfer of patients; adjustments to housekeeping and patient transport priorities and staffing decisions to improve patient flow; nursing level decisions in view of patient care requirements; bed assignment modifications and/or changes in priorities for patients to be admitted; clinical order prioritization adjustments for labs, imaging facilities and pharmacy units; changes to scheduled surgeries; and/or emergency room diversions.
Regardless of how a patient arrives at the current state 320, there may be an entry and departure time associated with the current state 320. The Length Of Stay (“LOS”) in the current state 320 is the difference between the “current time” and the “entry time” to the state. How long a patient stays in the current state 320 may be based on many factors including pre-determined fixed time durations, patient attributes 330 (e.g., his or her acuity level), primary diagnoses, care activity times that have random distributions, availability of resources needed to perform the required care activity, and/or the dynamics of the system (e.g., the readiness of a next state to accept the patient with bed and/or nurse availability). The model may have a transfer function with the proper fidelity to “predict” the remaining LOS in the current state 320 by a patient.
In general, there are two possibilities for the next destination or state when the patient is ready or allowed to leave the current state 320: departure from the throughput system or entry into a next state (e.g., for queuing or additional care activity). The next step decision might be based on historical patterns (e.g., ED patients have 83% chance to be discharged or a 17% chance to be admitted) or based on a rule or condition (e.g., surgical patients must go to a PACU area for recovery). If the next state is not an exit, there may be a single or multiple possible next states (locations). In the case of multiple possible next states, the choice may be random (driven by historical patterns) or may depend on a rule. For example, for ED patients to be admitted into an inpatient unit there might be a set of specific units with a preferred order. If no space is available in any of those units, there may be less-desired alternatives. If none of those less-desired options are viable, the patient may need to remain in ED until a bed becomes available.
A patient move from the current state 320 to the next state may require additional resources, which may make the move times unpredictable. For example, a patient who must have a Computed Tomography (“CT”) exam performed might need to wait until a transport with a wheelchair becomes available. If the wheelchair is not available, the patient transport may be delayed along with the CT exam process which, in turn, may further delay this particular patient's and other patients' flow through the system. In general, the system resources are limited in number and in resource availability can have a substantial impact on patient wait times and overall system throughput.
Such a patient flow 400 illustrates the complexity of a typical hospital system, which involves many linked components and high levels of variability. Note that new patient arrivals may be scheduled or unknown. Inpatient services may involve units of varying specialization that typically contain between 12 and 36 beds, and disposition from inpatient units may proceed to other parts of the flow 400 or to an external destination. In addition to the flow illustrated in
Note that patients may be delayed at any step due to capacity restrictions or “workflow” requirements such as surgical or emergency processes. The progress of a patient through the flow 400 may be highly uncertain and small deviations in patient flow can lead to substantial delays across the system if not addressed proactively. Managing patient throughput poses complex operational decisions over time scales from minutes to days. Some examples: whether “swing” capacity should be opened to avoid an upcoming bed-availability crisis; whether unit staffing should be revised to accommodate fewer (or more) patients; the range of admissions (or discharges) that should be expected today in each area and the likelihood that particular areas will be unable to accommodate demand; whether admissions from ED should be re-prioritized versus surgery units; whether some units need priority for bed cleaning or transportation; and/or where pending admissions should be sent in order to minimize potential bottlenecks while still maintaining appropriate levels of care.
The hospital flow 400 presents considerable uncertainty and numerous interdependencies, and a “whole hospital” forecast may address both of these issues and may: reflect system-wide interconnections; incorporate real-time data updates (including current patient status and any capacity or throughput restrictions); be able to model potential alternative tactics as well as “typical” behaviors; and/or avoid use of clinical health information (which may be subject to privacy restrictions). According to some embodiments, a system level discrete event simulation based on patient level data may be provided.
Note that each of the units illustrated in the hospital patient flow 400 may itself comprise a number of units. For example,
The inpatient services 630 units might represent locations where a patient spends at least one night in the hospital in order to go through the care plan appropriate for his or her treatment. The patients who are medically ready to leave the hospital are “discharged.” Sometimes a patient may be “transferred” to another inpatient services 630 unit to continue their care process.
Note that surgical patients are usually scheduled in advance. However, sometimes unscheduled surgeries (e.g., due to an emergency) are added to the schedule with little advance notice and this may impact the flow of scheduled patients. A surgery may require a patient to be admitted to an inpatient unit or a patient may be discharged after the surgery. The high level steps for surgery patients may include pre-operation activities to prepare the patient for the surgery, a holding stage where additional exams by the surgeon, nurse and the anesthesiologist may be conducted, the operating room where the actual surgery takes place, and a recovery room PACU to assure that the patient is medically ready to move on. At any given time, a surgical patient may be in any one of these value-added states or may simply be waiting for the resources or capacity (staff, equipment, room, etc.) to become available.
Patient arrivals to the ED are usually unscheduled. The first step is usually a triage activity to prioritize the care needed based on the patient's acuity level. Once the triage and the registration processes are completed, the patient waits until there is a room/bay available for the assessment and treatment. Due to random arrivals and dynamic acuity levels, the patient's priority may change frequently as new patients arrive into the system. Once a space becomes available, several nursing and physician assessments are conducted, clinical orders (lab, imaging, etc.) may be placed and fulfilled, and eventually a disposition decision is made whether to admit or discharge the patient.
The level of detail needed to accurately represent the real system and to predict its capacity in the future depends on the data availability and the objectives of the prediction capability. Some embodiments described herein provide a flexible, scalable and generic capability to model the transfer function properly. Moreover, some embodiments may leverage a generic, data driven, parametric simulation modeling toolkit to model complex hospital operations by taking into consideration the interdependencies and the randomness contained therein.
The data from the hospital information system 720 may be used to extract information to characterize the hospital and its historical behavior. Automated data mining and knowledge extraction methods may be used to define, store and translate this information into a usable form for the hospital system transfer function. Typical information includes the names, location and the capacity for patient care units including the ED, PERIOP, intensive care units, where the required care is provided to the patients at this specific hospital as well as the processes and the resources required to deliver a specific type of care. The historical information for patient arrival volumes and patterns, process times, disposition probabilities, and discharge and transfer patterns and volumes may also be extracted from the data in order to be able to execute the operations of the molecule 310 structure described with respect to
The model generation may comprise a one-time event for a particular site even though modifications to the structure and data may later be made to match the real-system evolution. An automated analytical workflow may drive the operational decisioning cycle which starts with an automatic capture of the “current” state at pre-defined intervals. For example, a snapshot of the system may be transmitted to an analysis engine input processor 720 at 6:00 AM, noon, 3:00 PM and 6:00 PM to update the forecast with the latest information during the period where there are significant patient flow activities such as new admits, surgery completions, discharges, and transfers. This real time information may include current state data such as patient location, workflow state, bed and resource availability, queue information, etc., and “scheduled” activities for surgery, external patient arrivals, etc. After being obtained, this information may be automatically processed for initializing or “hot-starting” the model and placed in a database for running simulation replications. Multiple replications may be executed, either in serial or parallel, to help quantify the potential range of future variation to be expected. Once replications are completed, the automated analytical workflow may distill the simulation output, perform the analysis required to forecast hourly bed availability/occupancy for each care unit/service/whole hospital and display them via a decisioning User Interface (“UI”) 740 and a prediction UI 750 via an analysis engine toolkit 730. The prediction UI 750 may be used to provide data to a decision support configurator 760 and the decisioning UI 740 may provide data to a background monitoring and learning component 770 at the end of the cycle.
Depending on how the system is set up, both running the simulation analysis and viewing the report could take place either in a cloud environment or on premise at the hospital. The system may, according to some embodiments, host certain analytical workflow steps on premise and other steps in a cloud.
Real-time input data might be obtained, for example, from an AgileTrac™ system available from GENERAL ELECTRIC CORPORATION® which has interfaces to multiple hospital information systems and databases. According to some embodiments, data may be provided as encrypted hourly “snapshots” describing the current state of all beds, patients, surgical cases, and bed requests across the hospital. Only a small subset of the data available in each source might be actually extracted for a “snapshot” to avoid use of private health data. Specific sources for a “snapshot” might include: an ADT database (indicating location, entry time and current status of each patient); surgical schedule, covering planned procedures and case start/end types; surgical workflow status, which tracks patient progress through various stages such as Pre-Op, Operating Room (“OR”) and recovery; bed requests (admission orders) for current and pending patients, listing basic needs such as specialty (orthopedics, cardiology, etc.), wait times and other criteria; discharge orders, indicating whether pending or confirmed and time order was written; and/or a bed board listing each inpatient bed and its current status (e.g., occupied, available/clean, available/dirty, cleaning in progress, blocked or otherwise out of service).
Note that data processing, simulation runs, and post-processing may be conducted on a dedicated secure server. Forecast reports may be generated and sent via e-mail to a configurable distribution list, and also encrypted and transferred to a cloud-hosted service for a controlled set of users to view on secure, password-protected web pages. According to some embodiments, outputs are used to create different types of display and reports for specific audiences.
As part of initial system set up for a new facility, the hospital's capacities, patient pathways across locations, and care types may be determined. The initial set up may be performed manually, utilizing historical patterns extracted from a AgileTrac™ data or any other hospital information system database archive including durations for length of stay in various units and care types, dispositions for patient movement between units, volumes of unscheduled arrivals, and variances within workflows. According to some embodiments, generating such patterns may be manually performed (e.g., by running a set of pre-defined SQL queries on a particular date range of historical data). According to other embodiments the generation of these patterns is automated.
The data mining for care pathways may be performed on a “first-principles” assumption that there are a limited (and known) number of paths by which patients can enter and exit each location. Some embodiments systematically extract the appropriate patterns and probabilities for each path based on the specific interconnections of a particular hospital's simulation model.
Note that the evaluation of real-time input may be fully automated. According to some embodiments, encrypted “snapshots” are sent to a system every hour, restored to a local database for processing, and used to modify the simulation model and generate entities reflecting known current/future patients and events.
All inpatient units may be updated with a current number of potential beds by computing the total bed count and subtracting any blocked (out of service) beds. Each current and scheduled patient may, for example, be placed into one of a number of categories (as defined during model configuration, potentially differing for each healthcare facility) based on the data types present for them, which guides their specific care path. Each patient's category may be used to apply stochastic parameters and generate 100 replications (potential future paths) for that patient.
The simulation model may be “hot-started” by placing patients in their current locations with pre-elapsed stay durations (rather than the model beginning with an empty hospital), followed by adding future known/scheduled events such as planned admissions or surgical cases, and probabilistically-generated unscheduled arrivals of various types. 100 replications may be generated for all current patients as well as for future events and unscheduled arrivals, covering volume, arrival timing, and movement paths through the system. The model may be associated with a generic and parametrically driven discrete-event simulation construct built on an AnyLogic™ or any other simulation platform (which might requires little re-coding to accommodate different hospitals or care pathways).
The embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 910 also communicates with a storage device 930. The storage device 930 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 930 stores a program 912 and/or a healthcare enterprise simulation model 914 for controlling the processor 910. The processor 910 performs instructions of the programs 912, 914, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 910 may receive snapshot data indicative of a current state of resources that deliver healthcare to a plurality of patients associated with a healthcare enterprise. The received snapshot data may be used by the processor 910 to initialize the healthcare enterprise simulation model 914. The healthcare enterprise simulation model 914 may then be executed to automatically generate a predicted future state of the resources at a predetermined point in time.
The programs 912, 914 may be stored in a compressed, uncompiled and/or encrypted format. The programs 912, 914 may furthermore include other program elements, such as an operating system, clipboard application, a database management system, and/or device drivers used by the processor 910 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the healthcare enterprise resource prediction platform 900 from another device; or (ii) a software application or module within the healthcare enterprise resource prediction platform 900 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The unit identifier 1002 may be, for example, a unique alphanumeric code identifying an area within a hospital (e.g., an emergency room, surgery area, etc.) as illustrated by the unit name 1004. The time-based resource predictions 1006, 1008, 1010, 1012 may represent an amount of a resource that is predicted to be available at a particular time. For example, it is predicted that the emergence room (“U—101”) will have 12 beds available at 6:00 PM and 8 beds available at midnight. In other embodiments, these predictions may be accompanied by confidence intervals or other estimates of variance. This information may then be used to make staffing decisions, patient routing decisions, etc.
Thus, embodiments described herein may provide automated resource and patient flow management. Moreover, the process may be based on a large scale discrete-event simulation covering the entire hospital ecosystem. For example,
At 1120, resource snapshot data may be received. According to some embodiments, the simulation is “hot-started” to reflect current hospital conditions including capacities and workflow in emergency, surgery, admitting clinics and inpatient units, and populated with the current, scheduled and “potential” patients expected across the next 24 hours. According to some embodiments, algorithms provide for differing care pathways and practice patterns of individual institutions and care providers.
Upon forecast initiation, data may be extracted from multiple hospital databases and information systems. According to some embodiments, current patients, beds, and in-progress surgeries are provided to the system as a “snapshot” in time. This may include data on each patient's location, entry time and status; the status of each inpatient bed (occupied, available, dirty/clean, out of service); and/or the current status of each surgery (patient in holding, pre-op, OR, recovery, etc.). The model may also utilize planned events such as upcoming surgeries or orders for admission and discharge. Moreover, a large amount of historical patterns may be extracted from previous data to describe the classification scheme for current patients along with potential outcomes (in terms of durations, next-state locations and probabilities) and unscheduled arrival rates and associated pathways through the system.
At 1130, the simulation model may be run forward to predict future resources (which may also be based on scheduled and predicted events). Note that a transfer function operates between inputs and the output predicted future resources. This step may include categorizing each current patient into one of 50 operational modes based on the data available for them (e.g., inpatient with discharge order, surgical patient currently in pre-op, with admission order, or emergency patient, recently arrived, no other data). For each replication of the simulation, a single duration and outcome may be selected for each patient. Each inpatient unit may be assigned its current in-service bed capacity and patients may be initialized into their current locations and states. External arrivals may be added to the simulation based on scheduled cases, pending direct-to-unit admission requests and probabilistic arrival tables. Note that each of these arrival types may have an associated range of variability and outcome, such as the likelihood that a scheduled case will proceed as planned. Finally, all of these elements may be simulated while accounting for priorities and conflicts between patients (competing for inpatient beds or other capacity), and replicated 100 times with potential for different durations, outcomes and arrivals each time.
At 1140, the predicted future resources may be output. According to some embodiments, after a simulation concludes, outputs from all replications may be automatically aggregated and processed to calculate statistics and generate reports that list a forecast output.
At 1150, the predicted future resources may be checked for potential bottlenecks. For example, once a prediction UI is provided, the system may run multiple scenarios configured by the user to reflect the impact of the real life operational decisioning one would take under the constrained capacity conditions. Some of these mitigations may include adding more staff, opening a surge unit, expediting discharges or transfers, canceling admissions, surgical procedures, and maybe even diverting new ED patients to other hospitals. As an example, the future state of cardiology resource availability could be improved if certain actions as configured would take place to avoid expected future bottlenecks. When the Cardiology service line is expected to have bed shortages two hours after the current forecast, it might be determined that the severity of the shortage can reduced by increasing the staffed beds in cardiology units.
The operational decision support cycle supported by the automated analytical workflow may end once the prediction and mitigation reporting is provided to decision-makers (and this cycle may repeat periodically). At 1160, the simulation model may be monitored and/or adjusted as appropriate based on the actual resources that where available at the predicted time. For example, the system and method for forecasting key resource bottlenecks may also be able to monitor the “accuracy” of the predictions and proposed mitigation actions. According to some embodiments, capabilities for background monitoring and learning may also be provided. More specifically, the system may include components for monitoring: the validity of the key historical patterns (e.g., ED arrival rates, volume, patterns, and discharge patterns) and assumptions used in the model; prediction accuracy (e.g., did the system predict occupancy/bed availability correctly at the right time in the right quantity at the right place) including trends; and mitigation accuracy (e.g., did the proposal for mitigation work as expected). The analytical workflow may automatically generate these reports and provides alerts/flags to appropriate users for further analysis for a possible change in the model structure and data assumptions. The process may then continue at 1120 (without reconfiguring the simulation model).
In this way, multiple simulation runs may be analyzed and digested into patient flow and census estimates at the level of individual units, service lines (unit groupings such as heart or medical) and/or the “whole hospital” (all adult-acute patients). Various dashboard views may be created for specific audiences such as unit managers, service line directors, support services, and/or a bed-placement team. Some views may be available through a secure password-protected website using cloud services while others are provided through email (as a message or as an attachment).
This high-level display 1200 may mask some of the interdependencies within the system, and therefore more granular detail may be available for different audiences.
According to some embodiments, customizable alerts can be generated based on specific forecast conditions.
Although some resource prediction displays are provided herein as examples, note that any number of other displays might also be provided. For example, a “heat map” could display forecasted arrival/exit activity by floor, which might help cleaning and transportation staff identify priorities and potential hot-spots across the day. The generated alerts based on forecasted conditions may also be customized, such as a special alert automatically transmitted to a predetermined set of health care providers upon a likelihood of extremely high occupancy. The alerting system may be customized to evaluate other user-defined conditions, such whether the estimated number of arrivals for a particular location exceeds some threshold. These alerts may, for example, be provided through email.
In addition to displays and alerts based on predicted resource information, note that GUIs may facilitate the entry of configuration data for a simulation model. For example,
According to some embodiments, an automated daily calibration may be performed for validation and verification based on a separate snapshot containing the past 24 hours of actual data and compared against the previous day's forecast. This process generates daily reports and long-term monitoring of historical patterns. The daily forecast accuracy might be measured at several levels of granularity, such as all beds in total, service lines, and/or 28 individual units and/or any other grouping as defined during the hospital configuration step.
For long-term monitoring, control charts may be used to monitor the deviation of various patterns to the corresponding real-life data day-by-day and aggregated over time. A control chart may be plotted using daily normalized values to determine whether observed values are within 3 sigma deviation of the estimated value. For certain patterns a quantile-quantile (q-q) plot may be generated to compare the observed cumulative distribution versus the assumed distribution (e.g., to evaluate patient length-of-stay distributions for two separate days of week). Positive and negative cusum values may be calculated over time to identify any statistical shifts between actual values and those expected from the patterns, and can provide notification that a pattern update may be required.
For offline pattern monitoring, an application may store daily calibration statistics and produce a calibration metric database, which enables charting or statistical analysis to identify problem areas and identify aspects of the system performance which can be improved. This may be helpful to visualize large amounts of data and make comparisons between units, service lines, and other groupings. It may also be used to locate interdependencies and imbalances between metrics. For example, one unit within a service line may be receiving too many patient arrivals while another within the same group receives too few. This may require a configuration update to balance out the probabilities of transfer within the set of units.
Scheduled pattern updates may occur periodically, such as every three months, and revisions may be performed based on rolling historical data, ensuring that long term variation is captured in the forecast. In addition to scheduled maintenance, there may be unscheduled modifications due to changes in hospital structure or operations (e.g., changes in workflow, units, or service lines). For example, when a new unit is added to the hospital it may be manually inserted into the simulation model and appropriate patterns may be selected based on assumed “comparable” units—until a sufficient time period has elapsed to permit historical pattern extraction. Code updates to the system might not be required unless there is a new feature to be added or bugs are discovered.
The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with some embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems).
Applicants have discovered that embodiments described herein may be particularly useful in connection with resource predictions for a healthcare enterprise. Note, however, that other types of predictions may also benefit from the invention.
The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.
The present application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/712,629 entitled “SYSTEM AND METHOD TO FORECAST KEY RESOURCE BOTTLENECKS IN A HOSPITAL FOR PROACTIVE OPERATIONAL DECISION SUPPORT” and filed on Oct. 11, 2012. The entire content of that application is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61712629 | Oct 2012 | US |