Patent Publication Number: US-2015088539-A1

Title: Methods and systems for optimizing patient allocation

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims priority from U.S. Provisional Patent Application No. 61/881,010, filed on Sep. 23, 2013, entitled “Methods and Systems for Optimizing Patient Allocation,” which is hereby incorporated by reference. 
    
    
     BACKGROUND 
     The disclosure relates to patient allocation. More particularly, the methods and systems described herein relate to optimizing patient allocation. 
     Conventional approaches to managing large groups of physicians do not typically provide functionality for making data-driven decisions regarding case management. This is due, in large part, to the fact that there is so much rapidly changing data, especially in groups including hundreds or thousands of physicians each with dozens or hundreds of patients and constantly seeking to grow their practices. Furthermore, each physician&#39;s workload is susceptible to change at any moment since multiple entities may be authorized to increase the workload—for example, one colleague may refer a patient to a specialist while an operator at a call center schedules a new patient to the same specialist and another operator makes an appointment with the specialist for an existing patient whose primary physician is unavailable, none of whom are required to confirm that the specialist is in fact the best person to treat their respective patients. It is therefore inefficient, if not completely infeasible, to manually receive an accurate portrayal of a particular physician&#39;s workload and analyze it in comparison to another physician without the resulting analysis being obsolete before it is even completed. To the extent that any human might attempt to manage the workload of a group of physicians, such humans typically use their own intuitions about whether a particular physician&#39;s workload is appropriate, not data resulting from scientific research. 
     However, given the nature of a physician&#39;s work, there may be serious, if not fatal, consequences to suboptimal patient allocation. Conventional groups of physicians typically suffer from long wait times for certain practitioners while other, potentially qualified, practitioners are underutilized. Under-qualified practitioners may suddenly face a heavy workload due to an influx of referrals but may not be able to receive the supervision needed to provide proper treatment, an especially serious issue given that research indicates that a minimum threshold of clinical fluency is critical in providing appropriate patient care. 
     BRIEF SUMMARY 
     In one aspect, a method for optimizing patient allocation includes analyzing qualifications of physicians and determining whether to transition responsibility between physicians all in real-time and taking into account rapidly changing data sets. The method includes determining, by an analysis engine executing on a computing device, for a type of procedure, a total number of procedures performed by a plurality of physicians. The analysis engine determines a percentage of the total number of procedures performed by each of the plurality of physicians. The analysis engine determines whether the determined percentage for a first physician is lower than a threshold. The analysis engine determines whether the determined percentage for a second physician is lower than the threshold. An allocation engine executing on the computing device transitions responsibility for at least one procedure performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is lower than the threshold and that the determined percentage for the second physician is higher than the threshold. 
     In another aspect, a method for optimizing patient allocation includes determining, by an analysis engine executing on a computing device, for a type of procedure, a total number of procedures performed by a plurality of physicians. The analysis engine determines a percentage of the total number of procedures performed by each of the plurality of physicians. The analysis engine determines whether the determined percentage for a first physician is lower than a first threshold. The analysis engine determines that the determined percentage for a second physician is higher than the first threshold and lower than a second threshold. An allocation engine executing on the computing device transitions responsibility for at least one procedure performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is lower than the first threshold. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing and other objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by referring to the following description taken in conjunction with the accompanying drawings, in which: 
         FIGS. 1A-1C  are block diagrams depicting embodiments of computers useful in connection with the methods and systems described herein; 
         FIG. 2A  is a block diagram depicting one embodiment of a system for optimizing patient allocation; 
         FIG. 2B  is a block diagram depicting one embodiment of a data structure generated by an analysis engine and storing determined calculations; 
         FIG. 3A  is a flow diagram depicting one embodiment of a method for optimizing patient allocation; and 
         FIG. 3B  is a flow diagram depicting another embodiment of a method for optimizing patient allocation. 
     
    
    
     DETAILED DESCRIPTION 
     In some embodiments, the methods and systems described herein provide functionality for optimizing patient allocation. Before describing such methods and systems in detail, however, a description is provided of a network in which such methods and systems may be implemented. 
     Referring now to  FIG. 1A , an embodiment of a network environment is depicted. In brief overview, the network environment comprises one or more clients  102   a - 102   n  (also generally referred to as local machine(s)  102 , client(s)  102 , client node(s)  102 , client machine(s)  102 , client computer(s)  102 , client device(s)  102 , computing device(s)  102 , endpoint(s)  102 , or endpoint node(s)  102 ) in communication with one or more remote machines  106   a - 106   n  (also generally referred to as server(s)  106  or computing device(s)  106 ) via one or more networks  104 . 
     Although  FIG. 1A  shows a network  104  between the clients  102  and the remote machines  106 , the clients  102  and the remote machines  106  may be on the same network  104 . The network  104  can be a local-area network (LAN), such as a company Intranet, a metropolitan area network (MAN), or a wide area network (WAN), such as the Internet or the World Wide Web. In some embodiments, there are multiple networks  104  between the clients  102  and the remote machines  106 . In one of these embodiments, a network  104 ′ (not shown) may be a private network and a network  104  may be a public network. In another of these embodiments, a network  104  may be a private network and a network  104 ′ a public network. In still another embodiment, networks  104  and  104 ′ may both be private networks. 
     The network  104  may be any type and/or form of network and may include any of the following: a point to point network, a broadcast network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an ATM (Asynchronous Transfer Mode) network, a SONET (Synchronous Optical Network) network, an SDH (Synchronous Digital Hierarchy) network, a wireless network, and a wireline network. In some embodiments, the network  104  may comprise a wireless link, such as an infrared channel or satellite band. The topology of the network  104  may be a bus, star, or ring network topology. The network  104  may be of any such network topology as known to those ordinarily skilled in the art capable of supporting the operations described herein. The network may comprise mobile telephone networks utilizing any protocol or protocols used to communicate among mobile devices, including AMPS, TDMA, CDMA, GSM, GPRS, or UMTS. In some embodiments, different types of data may be transmitted via different protocols. In other embodiments, the same types of data may be transmitted via different protocols. 
     A client  102  and a remote machine  106  (referred to generally as computing devices  100 ) can be any workstation, desktop computer, laptop or notebook computer, server, portable computer, mobile telephone or other portable telecommunication device, media playing device, a gaming system, mobile computing device, or any other type and/or form of computing, telecommunications or media device that is capable of communicating on any type and form of network and that has sufficient processor power and memory capacity to perform the operations described herein. A client  102  may execute, operate or otherwise provide an application, which can be any type and/or form of software, program, or executable instructions, including, without limitation, any type and/or form of web browser, web-based client, client-server application, an ActiveX control, or a Java applet, or any other type and/or form of executable instructions capable of executing on client  102 . 
     In one embodiment, a computing device  106  provides functionality of a web server. In some embodiments, a web server  106  comprises an open-source web server, such as the APACHE servers maintained by the Apache Software Foundation of Delaware. In other embodiments, the web server executes proprietary software, such as the Internet Information Services products provided by Microsoft Corporation of Redmond, Wash.; the Oracle iPlanet web server products provided by Oracle Corporation of Redwood Shores, Calif.; or the BEA WEBLOGIC products provided by BEA Systems of Santa Clara, Calif. 
     In some embodiments, the system may include multiple, logically-grouped remote machines  106 . In one of these embodiments, the logical group of remote machines may be referred to as a server farm  38 . In another of these embodiments, the server farm  38  may be administered as a single entity. 
       FIGS. 1B and 1C  depict block diagrams of a computing device  100  useful for practicing an embodiment of the client  102  or a remote machine  106 . As shown in  FIGS. 1B and 1C , each computing device  100  includes a central processing unit  121 , and a main memory unit  122 . As shown in  FIG. 1B , a computing device  100  may include a storage device  128 , an installation device  116 , a network interface  118 , an I/O controller  123 , display devices  124   a - n , a keyboard  126 , a pointing device  127 , such as a mouse, and one or more other I/O devices  130   a - n . The storage device  128  may include, without limitation, an operating system and software. As shown in  FIG. 1C , each computing device  100  may also include additional optional elements, such as a memory port  103 , a bridge  170 , one or more input/output devices  130   a - 130   n  (generally referred to using reference numeral  130 ), and a cache memory  140  in communication with the central processing unit  121 . 
     The central processing unit  121  is any logic circuitry that responds to and processes instructions fetched from the main memory unit  122 . In many embodiments, the central processing unit  121  is provided by a microprocessor unit such as: those manufactured by Intel Corporation of Mountain View, Calif.; those manufactured by Motorola Corporation of Schaumburg, Ill.; those manufactured by Transmeta Corporation of Santa Clara, Calif.; those manufactured by International Business Machines of White Plains, N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale, Calif. The computing device  100  may be based on any of these processors, or any other processor capable of operating as described herein. 
     Main memory unit  122  may be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor  121 . The main memory  122  may be based on any available memory chips capable of operating as described herein. In the embodiment shown in  FIG. 1B , the processor  121  communicates with main memory  122  via a system bus  150 .  FIG. 1C  depicts an embodiment of a computing device  100  in which the processor communicates directly with main memory  122  via a memory port  103 .  FIG. 1C  also depicts an embodiment in which the main processor  121  communicates directly with cache memory  140  via a secondary bus, sometimes referred to as a backside bus. In other embodiments, the main processor  121  communicates with cache memory  140  using the system bus  150 . 
     In the embodiment shown in  FIG. 1B , the processor  121  communicates with various I/O devices  130  via a local system bus  150 . Various buses may be used to connect the central processing unit  121  to any of the I/O devices  130 , including a VESA VL bus, an ISA bus, an EISA bus, a MicroChannel Architecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or a NuBus. For embodiments in which the I/O device is a video display  124 , the processor  121  may use an Advanced Graphics Port (AGP) to communicate with the display  124 .  FIG. 1C  depicts an embodiment of a computer  100  in which the main processor  121  also communicates directly with an I/O device  130   b  via, for example, HYPERTRANSPORT, RAPIDIO, or INFINIBAND communications technology. 
     A wide variety of I/O devices  130   a - 130   n  may be present in the computing device  100 . Input devices include keyboards, mice, trackpads, trackballs, microphones, scanners, cameras, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, and dye-sublimation printers. The I/O devices may be controlled by an I/O controller  123  as shown in  FIG. 1B . Furthermore, an I/O device may also provide storage and/or an installation medium  116  for the computing device  100 . In some embodiments, the computing device  100  may provide USB connections (not shown) to receive handheld USB storage devices such as the USB Flash Drive line of devices manufactured by Twintech Industry, Inc. of Los Alamitos, Calif. 
     Referring still to  FIG. 1B , the computing device  100  may support any suitable installation device  116 , such as a floppy disk drive for receiving floppy disks such as 3.5-inch disks, 5.25-inch disks or ZIP disks, a CD-ROM drive, a CD-R/RW drive, a DVD-ROM drive, tape drives of various formats, USB device, hard-drive or any other device suitable for installing software and programs. The computing device  100  may further comprise a storage device, such as one or more hard disk drives or redundant arrays of independent disks, for storing an operating system and other software. 
     Furthermore, the computing device  100  may include a network interface  118  to interface to the network  104  through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25, SNA, DECNET), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), wireless connections, or some combination of any or all of the above. Connections can be established using a variety of communication protocols (e.g., TCP/IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, CDMA, GSM, WiMax, and direct asynchronous connections). In one embodiment, the computing device  100  communicates with other computing devices  100 ′ via any type and/or form of gateway or tunneling protocol such as Secure Socket Layer (SSL) or Transport Layer Security (TLS). The network interface  118  may comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing the computing device  100  to any type of network capable of communication and performing the operations described herein. 
     In some embodiments, the computing device  100  may comprise or be connected to multiple display devices  124   a - 124   n , of which each may be of the same or different type and/or form. As such, any of the I/O devices  130   a - 130   n  and/or the I/O controller  123  may comprise any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable or provide for the connection and use of multiple display devices  124   a - 124   n  by the computing device  100 . One ordinarily skilled in the art will recognize and appreciate the various ways and embodiments that a computing device  100  may be configured to have multiple display devices  124   a - 124   n.    
     In further embodiments, an I/O device  130  may be a bridge between the system bus  150  and an external communication bus, such as a USB bus, an Apple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a Super HIPPI bus, a SerialPlus bus, a SCl/LAMP bus, a FibreChannel bus, or a Serial Attached small computer system interface bus. 
     A computing device  100  of the sort depicted in  FIGS. 1B and 1C  typically operates under the control of operating systems, which control scheduling of tasks and access to system resources. The computing device  100  can be running any operating system such as any of the versions of the MICROSOFT WINDOWS operating systems, the different releases of the Unix and Linux operating systems, any version of the MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described herein. Typical operating systems include, but are not limited to: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, WINDOWS XP, WINDOWS 7, and WINDOWS VISTA, all of which are manufactured by Microsoft Corporation of Redmond, Wash.; MAC OS manufactured by Apple Inc. of Cupertino, Calif.; OS/2 manufactured by International Business Machines of Armonk, N.Y.; and Linux, a freely-available operating system distributed by Caldera Corp. of Salt Lake City, Utah, or any type and/or form of a Unix operating system, among others. 
     The computing device  100  can be any workstation, desktop computer, laptop or notebook computer, server, portable computer, mobile telephone or other portable telecommunication device, media playing device, gaming system, mobile computing device, or any other type and/or form of computing, telecommunications or media device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described herein. In some embodiments, the computing device  100  may have different processors, operating systems, and input devices consistent with the device. 
     In one aspect, the methods and systems described herein provide functionality for optimizing patient allocation. In one embodiment, the methods and systems described herein provide functionality for analyzing qualifications of physicians and determining whether to transition responsibility between physicians all in real-time and taking into account rapidly changing data sets. 
     Referring now to  FIG. 2A , a block diagram depicts one embodiment of a system for optimizing patient allocation. In brief overview, the system includes a machine  106   a , an analysis engine  202 , an allocation engine  204 , and a database  206 . In some embodiments, the machine  106   a  stores the database  206 . In other embodiments, a second machine  106   b  (not shown) stores the database  206 . 
     Referring now to  FIG. 3A , and in connection with  FIGS. 2A-2B , a flow diagram depicts one embodiment of a method  300  for optimizing patient allocation. In brief overview, the method  300  includes determining, by an analysis engine executing on a computing device, for a type of procedure, a total number of procedures performed by a plurality of physicians ( 302 ). The method  300  includes determining, by the analysis engine, a percentage of the total number of procedures performed by each of the plurality of physicians ( 304 ). The method  300  includes determining, by the analysis engine, whether the determined percentage for a first physician is lower than a threshold ( 306 ). The method  300  includes determining, by the analysis engine, whether the determined percentage for a second physician is lower than the threshold ( 308 ). The method  300  includes transitioning, by an allocation engine executing on the computing device, responsibility for at least one procedure performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is lower than the threshold and that the determined percentage for the second physician is higher than the threshold ( 310 ). 
     In more detail, the method  300  includes determining, by an analysis engine executing on a first computing device, for a type of procedure, a total number of procedures performed by a plurality of physicians ( 302 ). In one embodiment, an organization such as a hospital employs the plurality of physicians. Although the methods and systems described herein provide functionality applicable to organizations with any number of physicians, such methods and systems may be particularly helpful in managing organizations with large numbers of physicians. For example, some hospitals (or networks of affiliated hospitals) may employ hundreds or even thousands of physicians and implementing functionality for optimizing patient allocation may be particularly beneficial to such organizations. 
     In some embodiments, the healthcare organization employing the plurality of physicians provides the data analyzed by the analysis engine  202 . In one embodiment, the analysis engine  202  accesses a scheduling database to determine the total number of procedures performed by the plurality of physicians. In another embodiment, the analysis engine  202  accesses an electronic medical record database to determine the total number of procedures performed by the plurality of physicians. In still another embodiment, the analysis engine  202  accesses a billing database to determine the total number of procedures performed by the plurality of physicians. In yet another embodiment, the analysis engine  202  accesses a claims database (e.g., a database of claims made to insurance companies for reimbursement) to determine the total number of procedures performed by the plurality of physicians. 
     In some embodiments, the analysis engine  202  accesses at least one database of procedure-related data, the at least one database undergoing modification by one or more entities. For example, a hospital may authorize the analysis engine  202  to access “live” databases such as scheduling databases that are actively used to create and modify scheduling data related to the type of procedure. Providing the analysis engine  202  with access to databases that are in use and subject to ongoing modification may allow the analysis engine  202  to make more accurate determinations than if the analysis engine  202  were restricted to historical data. In some embodiments, the analysis engine  202  receives access to both databases of historical data and to databases subject to ongoing modification. 
     In one embodiment, the analysis engine  202  accesses a database  206  to determine the total number of procedures of a particular type performed by the plurality of physicians. In another embodiment, the analysis engine  202  determines the total number of procedures of the type performed during a retrospective time period (e.g., the previous day, month, quarter, year, and so on). For example, the analysis engine  202  may retrieve data from the database  206  to determine how many heart surgeries all of the physicians at a particular hospital performed during the previous year. In another embodiment, the analysis engine  202  determines the total number of procedures of the type for which the plurality of physicians have contemporaneous responsibility (e.g., on-going cases or cases assigned to the physicians as of the date of the analysis). In still another embodiment, the analysis engine  202  determines the total number of procedures of the type for which the plurality of physicians will, prospectively, have responsibility (e.g., a number of cases assigned to the physicians as of the date of the analysis plus a prediction as to how many cases the physicians will have in a future time period). A user of the system  200  may specify the time period, the type of procedure, or other data used by the analysis engine  202  during execution of the optimization method. 
     The method  300  includes determining, by the analysis engine, a percentage of the total number of procedures performed by each of the plurality of physicians ( 304 ). In one embodiment, the analysis engine  202  determines the percentage of the total number of procedures performed by each physician. For example, the analysis engine  202  may determine that 200 heart surgeries were performed in the previous year and the analysis engine  202  may determine that Doctor Smith performed 25% of those 200 heart surgeries. 
     The analysis engine  202  may access data stored in the database  206  to make the determination. Data may include, without limitation, information associated with an organization (such as a hospital), information associated with a physician, diagnosis code(s), procedure code(s), cost of procedure, patient length of stay in the organization, a type of admittance to the organization (e.g., emergency or elective), and a financial class of a patient (e.g., self-pay or Medicare). 
     As shown in  FIG. 2B , the analysis engine  202  may generate a table  210  or other data structure storing the determined total number and the determined physician percentages. In one embodiment, the analysis engine  202  makes the table  210  available to users of the system  200 . By way of example, and as shown in  FIG. 2B , the analysis engine  202  may determine that a plurality of physicians perform 200 heart surgeries a year and store that information in table  210 . Continuing with this example, the analysis engine  202  may determine that one of the plurality of physicians (“Smith” in the embodiment depicted in  FIG. 2B ) performed 40% of the 200 total heart surgeries while determining that a second of the plurality of physicians (“Miller” in the embodiment depicted in  FIG. 2B ) performed 5% of the 200 total heart surgeries. 
     The method  300  includes determining, by the analysis engine, whether the determined percentage for a first physician is lower than a threshold ( 306 ). In some embodiments, a user specifies the threshold. In other embodiments, the analysis engine  202  specifies the threshold. In some embodiments, the threshold is a percentage of a number of procedures performed by a second physician. In one of these embodiments, by way of example, the threshold is 60% of the procedures performed by the most experienced physician in the plurality of physicians. For example, and referring again to  FIG. 2B , Dr. Smith may be considered the most experienced physician for heart surgeries since she has performed a greater percentage of the 200 heart surgeries performed by the plurality of physicians than any of the other physicians. The threshold in such an example would therefore be 25% (e.g., 200*0.41 is 82 heart surgeries by Dr. Smith, 82*0.6=49 heart surgeries; 49/200=25%). In such an example, Dr. Jones would exceed the threshold since he has performed more than 25% of the total number of heart surgeries, but Drs. Williams and Miller would not meet the threshold. 
     As indicated above, in some embodiments, the threshold is specified as a relative value (for example, without limitation, a percentage of a number of another physician&#39;s procedures). In other embodiments, however, the threshold is a range of numbers. In still other embodiments, the threshold is a specific number. For example, either a user of the system  200  or an administrator of the analysis engine  202  may specify the number, or the analysis engine  202  may be configured to use a particular number during an initialization or configuration process. 
     In some embodiments, the threshold is a minimum clinical fluency threshold. In one of these embodiments, the threshold is determined based on scientific research focused on a particular type of procedure. In another of these embodiments, the threshold identifies a number of procedures below which it may be unsafe to have the physician perform the procedure. By way of example and without limitation, the user or the analysis engine  202  may access data (e.g., scientific research) to determine that when a physician performs less than 5% of the total number of procedures of a particular procedure type within a time period (e.g., a year), the quality of the physician&#39;s work suffers. Work quality may be determined by a user or by the analysis engine  202  and may be determined based on scientific research. For example, work quality may be determined based on how long a physician takes to complete a procedure, how well the patient recovers from the procedure, or how much the procedure costs. As another example, the analysis engine  202  may analyze medical data associated with procedures previously performed (e.g., billing data and insurance data) and determine that when physicians perform less than 5% of a total number of heart surgeries, each surgery costs more, the physicians take more time to complete the surgery, or the patient has an increased risk of dying. 
     In one embodiment, and as depicted in  FIG. 2B , the analysis engine  210  may store an indication of whether the determined percentage for the first physician is lower than the threshold. 
     The method  300  includes determining, by the analysis engine, whether the determined percentage for a second physician is lower than the threshold ( 308 ). In one embodiment, the analysis engine  202  determines whether the determined percentage for the second physician is lower than the threshold as discussed above. 
     By way of example and without limitation, and referring again to  FIG. 2B , in some embodiments, the analysis engine  202  may determine that a first physician&#39;s percentage falls below the threshold and that a second physician&#39;s percentage meets or exceeds the threshold (e.g., that Dr. Miller&#39;s percentage of a total number of heart surgeries performed in, for example, a year by Drs. Smith, Jones, Williams, and Miller falls below the threshold; and that Dr. Smith&#39;s percentage during a substantially similar time period meets or exceeds the threshold). Continuing with this example, the analysis engine  202  may determine that a number of cases currently assigned to the first physician (e.g., Dr. Miller) should be re-assigned to the second physician (e.g., Dr. Smith). The analysis engine  202  may determine that the first physician can complete certain procedures or patient-related activities based on an analysis of those procedures before the re-assignment (e.g., Dr. Miller may complete a post-operative treatment activity for a patient where she has already performed a surgery, but Dr. Smith should take over after completion of the treatment). Alternatively, the analysis engine  202  may determine to re-assign the first physician&#39;s procedure or activities as soon as practicable (e.g., if Dr. Miller has performed an initial evaluation of a patient and recommended a surgery, but has not yet scheduled the surgery, the analysis engine  202  may determine to re-assign the patient before the surgery). In other embodiments, the analysis engine  202  determines that a number of cases (e.g., patients or procedures) previously assigned to the first physician (e.g., in the last day, week, month, quarter, year, or other retrospective time period) fell below the threshold and that future cases that would have been assigned to the first physician should instead be assigned to the second physician (e.g., as opposed to determining that current caseload should be transitioned to the second physician as soon as practicable). The analysis engine  202  may determine that the first physician may continue his or her involvement in a procedure but under the supervision of the second physician. The analysis engine  202  may therefore determine to instruct the allocation engine to transition responsibility for at least one procedure. The analysis engine  202  may store an indication as to this determination; for example, the analysis engine  202  may store the indication in the table  210 . In some embodiments, the analysis engine  202  transmits the indication to the allocation engine  204 . In other embodiments, the allocation engine  204  retrieves the indication from the table  210 . 
     The method  300  includes transitioning, by an allocation engine executing on the computing device, responsibility for at least one procedure performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is lower than the threshold and that the determined percentage for the second physician is higher than the threshold ( 310 ). In one embodiment, the allocation engine  204  receives, from the analysis engine  202 , an instruction to transition responsibility for the at least one procedure. In one embodiment, the allocation engine  204  transitions responsibility for the procedures performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is substantially lower than the threshold and that the determined percentage for the second physician is substantially equal to or higher than the threshold. In some embodiments, the allocation engine  204  executes an algorithm for generating an optimal match between each of a number of physicians and an amount of available work. For example, the allocation engine  204  may determine to move a patient from an unqualified first doctor (e.g., a first doctor that did not substantially meet the threshold) to a more qualified second doctor (e.g., a second doctor that did substantially equal or exceed the threshold). As another example, the allocation engine  204  may determine to move a patient from a first doctor to a second doctor who is at least one standard deviation more experienced. In some embodiments, and as will be discussed in further detail in connection with  FIG. 3B , the allocation engine  204  then determines that the second doctor has too much work and reallocates the second doctor&#39;s work to a third doctor, repeating until the allocation engine  204  has addressed each of the plurality of physicians. 
     The allocation engine  304  may transmit, to a scheduling component (not shown), an instruction to modify a database entry identifying the first physician as responsible for the at least one procedure. The allocation engine  304  may transmit, to an electronic medical record management component (not shown), an instruction to modify a database entry identifying the first physician as responsible for the at least one procedure. 
     In one embodiment, the allocation engine  204  reallocates the procedures assigned to each of the plurality of physicians so that each procedure is assigned to a more qualified physician. In another embodiment, the allocation engine  204  is constrained by the physicians&#39; capacity. 
     In one embodiment, the allocation engine  204  identifies a plurality of patients (e.g., patients associated with a procedure) for whom a more experienced physician is available. In another embodiment, for each patient, the allocation engine  204  identifies at least one doctor with more experience than the patient&#39;s current doctor and attempts to find an allowable path from the patient&#39;s current doctor to the at least one doctor; an allowable path may, for example, be a path from doctor to doctor to doctor in a plurality of available doctors, such that each doctor has a patient that is allowed to be seen by the next doctor in the path. In one embodiment, the search for the path is a breadth-first search. In some embodiments, once the allocation engine  204  identifies an allowable path, each of the plurality of patients is reallocated to the new doctors in the path. If a second patient is moved to a better physician during the course of reallocating a first patient through an allowable path, the second patient is removed from the plurality of patients for whom a more experienced physician is available. 
     In some embodiments, the allocation engine  204  executes a version of the Gale-Shapley algorithm or other algorithm for solving the “stable marriage problem.” In other embodiments, the allocation engine  204  executes an algorithm to optimize an existing pairing between available work and available physicians, as opposed to using the algorithm to create an initial pairing between available work and available physicians. In other embodiments, the allocation engine  204  executes an algorithm to ensure an optimized pairing of existing work and available physicians before assigning new work to the available physicians. In other embodiments, the allocation engine  204  specifies that the algorithm generating the optimal match should determine how to allocate work amongst the plurality of physicians such that the percentage of the total amount of work falls substantially at the specified threshold for each physician. 
     In some embodiments, the allocation engine  204  may execute a secondary algorithm for reallocation. For example, if no optimal reallocations are available amongst physicians (e.g., the second physician recommended by the initial algorithm has too great a workload to take on the reallocation and there are no third physicians who could take on the overflow), the allocation engine  204  may identify a second-best physician based on weaker matching criterion. As another example, the allocation engine  204  may determine that, based on relative experience, although a second physician would be ideal, a third physician with less experience than the second has more experience than the first physician. For example, referring to  FIG. 2B , although the allocation engine  204  may primarily seek to reallocate work from Dr. Miller to Dr. Smith, if Dr. Smith cannot take on any additional procedures, patients, or other tasks, the allocation engine  204  may reallocate Dr. Miller&#39;s work to Dr. Jones who has also exceeded the threshold, although not by as much as Dr. Smith. As another example, the allocation engine  204  may seek to allocate a subset of the work (e.g., particular visit types) for which it can identify a suitable physician to which to reallocate the subset. 
     The system  200  may further execute a method to modify a previous optimization. Therefore, in one embodiment, the methods described herein include determining, by the analysis engine, that data relating to the total number of procedures has changed; automatically re-determining, by the analysis engine, whether the determined percentage for the first physician is lower than the threshold; automatically re-determining, by the analysis engine, whether the determined percentage for the second physician is lower than the threshold; and determining, by the analysis engine, whether to instruct the allocation engine to modify an identification of a physician responsible for the at least one procedure, based upon the re-determinations. Due to the system  200  functionality for continuously re-evaluating types of procedures and patient allocation data for each physician in a plurality of physicians, updating and modifying transitions of responsibility as appropriate, the system  200  may be said to operate in real-time. 
     In one embodiment, the analysis engine  202  and the allocation engine  204  operate automatically in order to dynamically identify procedures for which responsibility should be transferred from one physician to another. In addition to executing the methods described herein for each physician in a plurality of physicians once and identifying an optimal patient allocation for one patient or procedure at one point in time, the analysis engine  202  and the allocation engine  204  may continue executing the methods described herein and continually identify increased optimizations. By way of example, by the time the system  200  has completed identifying and transitioning responsibility for a first procedure or plurality of physicians, the data underlying those determinations may have been modified such that a new set of optimizations should be implemented. By continuously executing and by accessing active databases continuously susceptible to modification, the system  200  may provide automatic updates to optimizations, keeping pace with changes implemented at the organization of physicians. 
     Referring now to  FIG. 3B , and in connection with  FIGS. 2A-2B , a flow diagram depicts an embodiment of a method  320  for optimizing patient allocation. In brief overview, the method  320  includes determining, by an analysis engine executing on a computing device, for a type of procedure, a total number of procedures performed by a plurality of physicians ( 322 ). The method  320  includes determining, by the analysis engine, a percentage of the total number of procedures performed by each of the plurality of physicians ( 324 ). The method  320  includes determining, by the analysis engine, whether the determined percentage for a first physician is lower than a first threshold ( 326 ). The method  320  includes determining, by the analysis engine, that the determined percentage for a second physician is higher than the first threshold and lower than a second threshold ( 328 ). The method  320  includes transitioning, by an allocation engine executing on the computing device, responsibility for at least one procedure performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is lower than the first threshold ( 310 ). 
     The method  320  includes determining, by an analysis engine executing on a computing device, for a type of procedure, a total number of procedures performed by a plurality of physicians ( 322 ). In one embodiment, the analysis engine  202  performs this determination as described above in connection with  FIG. 3A . 
     The method  320  includes determining, by the analysis engine, a percentage of the total number of procedures performed by each of the plurality of physicians ( 324 ). In one embodiment, the analysis engine  202  performs this determination as described above in connection with  FIG. 3A . 
     The method  320  includes determining, by the analysis engine, whether the determined percentage for a first physician is lower than a first threshold ( 326 ). In one embodiment, the analysis engine  202  performs this determination as described above in connection with  FIG. 3A . 
     The method  320  includes determining, by the analysis engine, that the determined percentage for a second physician is higher than the first threshold and lower than a second threshold ( 328 ). In some embodiments, in addition to determining whether a physician is qualified (e.g., has seen enough patients to meet a quality threshold and will continue seeing those patients instead of having the patients reallocated to more qualified physicians), the analysis engine  202  determines whether the physician is seeing too many patients. For example, the analysis engine  202  may determine whether the physician has too large a percentage of the total number of procedures for any other physician to develop expertise in handling the type of the procedure. The analysis engine  202  may determine the second threshold based on user input to the system  200 . 
     The method  320  includes transitioning, by an allocation engine executing on the computing device, responsibility for at least one procedure performed by the first physician to the second physician, responsive to a determination that the determined percentage for the first physician is lower than the first threshold ( 330 ). In one embodiment, the allocation engine  204  performs this determination as described above in connection with  FIG. 3A . 
     In some embodiments, implementation of the methods and systems described herein may result in a system that accounts for a volume of work done by an organization (e.g., a hospital) and by members of the organization (e.g., a plurality of physicians at the hospital). In one of these embodiments, allocation of work to particular physicians may take into account whether the physician has a threshold level of experience in performing the work, instead of merely considering availability of the physician. 
     Although the embodiments described herein relate to optimization of allocations in a medical setting, one of ordinary skill in the art will understand that the methods and systems described herein may also relate to other industries. For example, management consultants, attorneys, salespeople, or other professionals may also have workloads optimized. 
     The systems and methods described above may be implemented as a method, apparatus, or article of manufacture using programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on a programmable computer including a processor, a storage medium readable by the processor (including, for example, volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code may be applied to input entered using the input device to perform the functions described and to generate output. 
     Each computer program within the scope of the claims below may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language. The programming language may, for example, be LISP, PROLOG, PERL, C, C++, C#, JAVA, or any compiled or interpreted programming language. 
     Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps of the invention may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the invention by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits) or FPGAs (Field-Programmable Gate Arrays). A computer can generally also receive programs and data from a storage medium such as an internal disk (not shown) or a removable disk. A computer may also receive programs and data from a second computer providing access to the programs via a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. 
     Having described certain embodiments of methods and systems for optimizing patient allocation, it will now become apparent to one of skill in the art that other embodiments incorporating the concepts of the disclosure may be used. Therefore, the disclosure should not be limited to certain embodiments, but rather should be limited only by the spirit and scope of the following claims.