Abstract:
A real-time status system for managing encounters in a health care facility is disclosed. The real-time status system includes a graphical user interface in communication with a health care scheduling system for accessing encounters, scheduling information for the encounters, and tracking information for the encounters. The real-time status of the encounters, generated and updated based on the scheduling information for the encounters and the tracking information for the encounters, is displayed on the graphical user interface. A scheduled status of the encounters based on the scheduling information for the encounters can also be displayed on the graphical user interface, and users can selectively view the real-time status and the scheduled status independently or simultaneously.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     The present invention relates generally to health care management, and more particularly to a system and method for providing a real-time status for managing encounters in a health care setting.  
         [0002]     In a health care setting, it is necessary to effectively and comprehensively manage the progress of encounters, such as surgeries or clinic appointments, from beginning to end. Encounters are usually scheduled, but cannot be managed based on the schedule alone because the encounters rarely proceed according to the schedule due to the many variables involved. For example, a surgical encounter in an operating room could exceed its scheduled time because one of the surgical procedures was more complicated than expected. Conversely, a surgical encounter could be completed earlier than its scheduled time because a scheduled surgical procedure could not be performed or was deemed unnecessary or unadvisable at some point during the surgical encounter. In addition, emergency surgical encounters must be performed before scheduled encounters of lower priority. All of these changes affect the rest of the encounters scheduled in the operating room, rendering the schedule alone an ineffective means for managing encounters. A doctor, for instance, cannot look at the schedule of encounters to accurately determine what time she needs to be ready to perform a surgical procedure on a patient. The encounter may be scheduled at  10 am, but for a number of reasons may not actually occur until several hours later. Moreover, in some health care settings, such as the emergency department, encounters are not scheduled at all, requiring another means for managing the encounters that come into the department.  
         [0003]     One method currently in use for managing encounters in connection with the schedule is a grease board. Some health care facilities use a grease board or dry erase board that can be manually updated to reflect encounter changes. Additionally, some health care facilities use an electronic version of the grease board that will, in some cases, automatically update based on encounter change and progress information entered into an electronic recordkeeping system. The grease board typically lists each encounter scheduled for a particular facility, such as a surgical department of a hospital, and displays each encounter&#39;s current status. For example, a grease board might list each surgical encounter scheduled in each operating room, along with each encounter&#39;s status, such as “scheduled,” “arrived,” “in progress” “in pre-op,” etc. The start and end times for each encounter may also be listed. In an emergency department, the grease board is sometimes the only visible record of the status of encounters in each treatment room.  
         [0004]     The grease board is a more effective tool for managing encounters than a schedule alone because it does give doctors and other health care practitioners more information regarding the current status of the encounters, instead of merely providing them with the scheduled status of the encounters. When a doctor looks at the grease board, for instance, and sees that the encounter scheduled immediately before her encounter started two hours later than scheduled, she knows that her encounter will be delayed by approximately two hours as well. Grease boards can also be color-coded, assigning a unique color to each status, such as blue for “in progress” encounters or red for “delayed” encounters, to alert users at a glance of the particular status of each encounter.  
         [0005]     Although the grease board provides additional information concerning the encounters, it too has significant limitations. For example, the grease board does not display the progress of the encounters in the most logical manner; instead, users must interpret the information presented on the grease board to get an adequate picture of the progress of the encounters. For example, the grease board typically presents information in a tabular format, as opposed to a graphical format. A graphical format would be more intuitive for users, allowing them to quickly view the progress of the encounters without the interpretation required with a tabular format. In addition, most grease boards are not able to calculate estimated start and end times for encounters based on previous encounter progress, or account for the addition of an emergency encounter or an encounter performed out of scheduled order without additional user intervention or interpretation of the data. Further, the grease board does not track the progress of encounters relative to the original schedule for the encounters. A charge nurse in a surgical facility, for instance, cannot look at the grease board alone to determine whether or not the encounters are proceeding as scheduled, or if the encounters need to be rescheduled or moved to other operating rooms.  
         [0006]     Given the limitations and problems with the prior art systems and methods described above, there exists a need for an improved system for managing encounters in a health care setting that can provide an accurate real-time status of the encounters in an intuitive graphical format. The present invention relates to improvements over the systems and methods described above, and to solutions to the problems raised or not solved thereby.  
       SUMMARY OF THE INVENTION  
       [0007]     The present invention provides a real-time status system for managing encounters in a health care setting. The real-time status system includes a graphical user interface in communication with a health care scheduling system for accessing encounters, scheduling information for the encounters, and tracking information for the encounters, and further includes a real-time status of the encounters displayed on the graphical user interface. The present invention provides a graphical representation showing the real-time status of encounters for patients in a health care setting. The real-time status is generated and updated based on the scheduling information for the encounters and the tracking information for the encounters. A scheduled status of the encounters based on the scheduling information for the encounters can also be displayed on the graphical user interface. The real-time status and the scheduled status can preferably be displayed in a graphical format or in a tabular format and are preferably displayed in connection with one another. The present invention compares scheduled encounter information with real-time encounter data to provide a real-time status system for use in viewing and managing the encounters at a glance.  
         [0008]     The real-time status system of the present invention calculates a real-time start time and real-time end time for each encounter and displays the real-time status of each encounter based on the real-time start time and the real-time end time for each encounter. The scheduled status of each encounter is displayed based on a scheduled encounter start time and a scheduled encounter end time for each encounter, which are stored in schedules for the encounters. Customizable and configurable visual cues such as icons and color codes are used to indicate characteristics of the displayed encounters. Users can preferably select from the displayed real-time status or scheduled status of one of the encounters and access additional information about the encounter.  
         [0009]     The present invention can display a real-time status for encounters in a number of different health care facilities, and for a number of different encounters. For example, the real-time status of encounters in each room of a health care facility, such as surgical encounters in each operating room in a surgical facility, could be displayed, or the real-time status of each health care practitioner in a health care facility, such as clinical encounters for each physician in a clinic, could be displayed. Further, the real-time status system can display the real-time status of encounters that have not been scheduled, and encounters that have been performed out of scheduled order.  
         [0010]     The present invention also contemplates a method for managing encounters in a health care setting. The method includes the steps of (1) providing a graphical user interface in communication with a health care scheduling system for accessing encounters, scheduling information for each encounter and tracking information for each encounter, (2) generating a real-time status for each encounter based on the scheduling information for each encounter and the tracking information for each encounter, and (3) displaying the real-time status of the encounters on the graphical user interface. The method can also include the step of updating the real-time status for each encounter, generating a scheduled status for the encounters based on the scheduling information for each encounter, and displaying the scheduled status on the graphical user interface.  
         [0011]     The real-time status system of the present invention has several advantages over the prior art systems. For example, the real-time status system provides an intuitive graphical representation of the real-time status of the encounters. Users do not need to interpret information presented in a tabular format. Moreover, users are able to track and view the progress of encounters relative to the schedule for the encounters because the real-time status of encounters can be displayed in connection with the scheduled status of the encounters, allowing users to quickly and easily compare the two statuses. The real-time status system of the present invention is further able to calculate estimated real-time start and end times for encounters, account for encounters performed out of order, and show emergency encounters without additional user intervention.  
         [0012]     Various other features, objects, and advantages of the invention will be made apparent to those skilled in the art from the accompanying drawings and detailed description thereof. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]      FIG. 1  is a sample screen shot illustrating an embodiment of the real-time status system of the present invention in a comparison view showing both the scheduled and the real-time status of encounters in several operating rooms;  
         [0014]      FIG. 1A  is a sample screen shot illustrating an embodiment of the real-time status system of the present invention in a comparison view showing both the scheduled and the real-time status of encounters for several physicians;  
         [0015]      FIG. 2  is a sample screen shot illustrating the real-time status system of the present invention in a “real-time only” view showing the real-time status of encounters in the operating rooms of  FIG. 1 ;  
         [0016]      FIG. 2A  is a sample screen shot illustrating the real-time status system of the present invention in a “real-time only” view showing the real-time status of encounters for the physicians of  FIG. 1A ;  
         [0017]      FIG. 3  is a sample screen shot illustrating the real-time status system of the present invention in a “scheduled only” view showing the scheduled status of encounters in the operating rooms of  FIG. 1 ;  
         [0018]      FIG. 3A  is a sample screen shot illustrating the real-time status system of the present invention in a “scheduled only” view showing the scheduled status of encounters for the physicians of  FIG. 1A ;  
         [0019]      FIG. 4  is a sample screen shot illustrating the real-time status system of the present invention showing an encounter being performed out of scheduled order;  
         [0020]      FIG. 5  is a sample screen shot illustrating the real-time status system of the present invention showing an emergency encounter being performed that was not first scheduled;  
         [0021]      FIG. 6  is a sample screen shot illustrating another embodiment of the real-time status system of the present invention showing a grease board view;  
         [0022]      FIG. 7  is a sample screen shot illustrating a color configuration screen for selecting the colors displayed in the real-time status system of the present invention;  
         [0023]      FIG. 8  is a sample screen shot illustrating an embodiment of an encounter tracking log for inputting information for various encounters of the present invention;  
         [0024]      FIG. 9  is a sample screen shot illustrating an embodiment of a configuration screen for configuring the encounter tracking log of the present invention;  
         [0025]      FIG. 10  is a flow diagram illustrating an example of logic used to calculate the real-time start time and the real-time end time for a single encounter using the present invention;  
         [0026]      FIG. 11  is a flow diagram illustrating an example of logic used to calculate the real-time start time and the real-time end time for all encounters in a single operating room using the present invention; and  
         [0027]      FIG. 12  is a graphical representation illustrating an example of an interaction between the real-time status system and the health care scheduling system of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0028]     The real-time status system of the present invention comprises a graphical user interface capable of displaying a real-time status of encounters in a health care facility. Encounters in a health care facility generally include anytime a health care practitioner has contact with a patient such as but not limited to clinical appointments, office visits, surgical cases, and any procedures, tests, and examinations. The health care practitioner can include all practitioners that work in the health care facility or have any contact with the health care facility or patients in the health care facility, including but not limited to doctors, nurses, physician&#39;s assistants, technicians, dieticians, nutritionists, police officers, counselors, pharmacists, nurse practitioners, emergency medical services personnel, and medical students.  
         [0029]     The real-time status system of the present invention generates and updates the real-time status, including a real-time start time and a real-time end time, based on scheduling information about the encounters recorded in schedules for the encounters and on actual tracking information about the encounters recorded in tracking logs. Schedules for the encounters include scheduled start times and scheduled end times for the encounters, and can be stored in any form, such as in a database, that is accessible to the real-time status system. Encounter tracking logs record actual start times and actual end times for each encounter, and if appropriate, for each event (panels, procedures, or tracked components thereof including start up or clean up events) within an encounter. The real-time start time and the real-time end time for each encounter correspond either to the actual start time and actual end time recorded in the tracking logs for the encounter, or to estimated start and end times calculated by the real-time status system of the present invention or entered by a user in the tracking log.  
         [0030]     The real-time status can be displayed in a number of formats, including a graphical format such as timelines or bar graphs as shown in  FIGS. 1-5 , and a tabular format such as a format similar to a traditional grease board as shown in  FIG. 6 . In addition, the real-time status can be organized in the display by a variety of tracking variables, such as by room as shown in  FIGS. 1, 2  and  3  and by physician or other heath care practitioner as shown in  FIGS. 1A, 2A  and  3 A. A room can be defined by the user as a traditional room, such as an operating room, or as any area in which an encounter might take place. For example, in an emergency department, a user may want to track encounters that occur in hallways as well as the waiting room and other areas within the emergency department.  
         [0031]     Referring now to the drawings,  FIG. 12  shows a graphical representation illustrating an example of an interaction between the real-time status system and the health care scheduling system of the present invention. In  FIG. 12 , the real-time status system  10  is in communication with a health care scheduling system  12  and a data repository  14 . The real-time status system  10  includes a graphical user interface that can communicate with the health care scheduling system  12 . The real-time status system  10  of the present invention interacts with the health care scheduling system  12  to access a diverse range of patient data, including health care facility encounters, scheduling information for the encounters, and tracking information for the encounters. All of the patient data could be stored in the health care scheduling system  12 , or some of the data could be stored in a separate data repository  14  as shown in  FIG. 12 . In that case, the real-time status system  10  would be in communication with both the health care scheduling system  12  and the data repository  14  as shown. The health care scheduling system  12  and data repository  14  could be part of a broader health information system, or could be separate systems interfaced together. The specific configuration of the health care scheduling system  12  is not particular to the present invention. However, the health care scheduling system  12  is preferably an integrated application within a health information system having a single data repository  14  capable of manipulating, processing, and sharing data. The health information system could interface with existing health care records management systems to receive information, or the health information system could receive such information through various integrated applications, such as the health care scheduling system  12 . The health information system could be configured to support a number of different applications to organize information into a universal patient record. A universal patient record preferably contains all available information referring to or involving a patient, including but not limited to clinical data, appointments and scheduling information, billing and payment status, and insurance and payor information. The health information system could be further configured to manage all aspects of a patient&#39;s medical care, including complete clinical, financial, and operational data relating to the patient.  
         [0032]      FIG. 1  is a sample screen shot illustrating an embodiment of the real-time status system of the present invention in a comparison view showing both the scheduled and the real-time status of encounters in several operating rooms.  FIG. 1  shows the real-time status and scheduled status of encounters in a surgical facility. An encounter in a surgical facility can be a surgical case, procedure, or operation, such as a splenectomy or endoscopy, and the real-time status system can be used to track the real-time status of the surgical encounter from beginning to end.  FIG. 1  shows a graphical user interface  16  displaying a window  18  of a health care scheduling system labeled “OR Scheduling.” The window  18  includes a timeline  20  and a column  22  listing the various operating rooms in the surgical facility. Each operating room listed in the column  22  has a first row dedicated to scheduled status  24  and a second row dedicated to real-time status  26 . The real-time status rows  26  include a lightning bolt icon  28  to distinguish the real-time status rows  26  from the scheduled status rows  24 . Other methods for distinguishing the real-time status from the scheduled status could also be used.  
         [0033]     In  FIG. 1 , the scheduled status for each encounter scheduled to take place in each operating room is displayed in each scheduled status row  24  underneath and corresponding to the timeline  20 . The timeline  20  is labeled at each hour  30  of the day and includes tick marks  32  to represent fifteen-minute intervals of time. The scheduled status of each encounter is shown as a bar graph beginning at the scheduled start time for the encounter and ending at the scheduled end time for the encounter. The scheduled status row  24  labeled “OR  1 ” shows the scheduled status for two encounters scheduled in operating room number  1 , the “Advent, Phyllis” encounter  34  and the “Billman, Penelope” encounter  35 . The scheduled status row  24  labeled “OR  2 ” shows the scheduled status of four encounters scheduled in operating room number  2 , the “Andrews, Cecily” encounter  36 , the “Bordel, Will” encounter  37 , the “Quaid, Connie” encounter  38 , and the “Harris, Anne” encounter  39 . The scheduled status row  24  labeled “OR  3 ” shows the scheduled status of four encounters scheduled in operating room number  3 , the “Gep, Bob” encounter  40 , the “Lassel, Tina” encounter  41 , the “Bilmore, Deacon” encounter  42 , and the “Weese, Charles” encounter  43 . The scheduled status of each encounter is shown in yellow to further alert the user that he or she is looking at a scheduled status for the encounter. Each scheduled status row  24  is shown in royal blue for time periods for which no encounters are scheduled.  
         [0034]     As also shown in  FIG. 1 , the real-time status for each encounter taking place or scheduled to take place in each operating room is displayed in each real-time status row  26  immediately below the corresponding scheduled status row  24 . Thus, as shown, the real-time status row  26  for operating room number  1 , labeled “OR  1 ” is displayed immediately below the scheduled status row  24  for operating room number  1 , labeled “OR  1 .” The real-time status row  26  labeled “OR  1 ” shows the real-time status for the two encounters scheduled in operating room number  1 , the “Advent, Phyllis” encounter  34   a  and the “Billman, Penelope” encounter  35   a . The real-time status row  26  labeled “OR  2 ” shows the real-time status of the four encounters scheduled in operating room number  2 , the “Andrews, Cecily” encounter  36   a , the “Bordel, Will” encounter  37   a , the “Quaid, Connie” encounter  38   a , and the “Harris, Anne” encounter  39   a . The real-time status row  26  labeled “OR  3 ” shows the real-time status of the four encounters scheduled in operating room number  3 , the “Gep, Bob” encounter  40   a , the “Lassel, Tina” encounter  41   a , the “Bilmore, Deacon” encounter  42   a , and the “Weese, Charles” encounter  43   a . Using this comparison view, it is easy for users to compare the scheduled status of the encounters to the real-time status of the encounters. In  FIG. 1 , for example, a user can compare the real-time status of the “Advent, Phyllis” encounter  34   a  to the scheduled status of the “Advent, Phyllis” encounter  34  and see that the encounter  34   a  actually started later than scheduled and is expected to end later than scheduled, which will also delay the next encounter  35   a . A user can also compare the real-time status of the “Gep, Bob” encounter  40   a  with the scheduled status of the “Gep, Bob” encounter  40  to see that the encounter  40   a  ended earlier than scheduled, which allowed the next encounter  41   a  to start earlier than scheduled. Thus, users can easily see which encounters are on schedule and which are early or delayed. A charge nurse could effectively use this comparison view to make decisions about scheduling new encounters and the need to reschedule existing encounters.  
         [0035]      FIG. 1  also shows the use of various visual cues with the real-time status system of the present invention. For example, color codes are used as visual cues. The real-time statuses of the encounters in  FIG. 1  are shown in multiple color codes that correspond to specific characteristics of the status of the encounters. The “Advent, Phyllis” encounter  34 a is shown in light pink to indicate that the patient, Phyllis Advent, has arrived in the operating room, the “Billman, Penelope” encounter  35   a  is shown in dark pink to indicate that the patient, Penelope Billman, is currently in the pre-op area, the “Gep, Bob” encounter  40   a  is shown in green to indicate that the patient, Bob Gep, has been discharged from the post-anesthesia care unit (PACU), and the “Lassel, Tina” encounter  41   a  is shown in purple to indicate that the patient, Tina Lassel, is in the operating room undergoing a surgical procedure. Other visual cues are also used, including icons. A down arrow icon  46  is used to indicate that an encounter is a low priority encounter, and an exclamation point icon  47  is used to indicate that an encounter is a high priority encounter. Any icon, color code, or other visual cue can be used to represent any number of different characteristics associated with the encounters, and the real-time status system of the present invention allows users to completely configure and customize the visual cues.  
         [0036]      FIG. 1  further shows that a user can select an encounter and view or access additional information about the encounter. In  FIG. 1 , a user has selected the “Advent, Phyllis” encounter  34  and an information summary box  48  or “tool tip” has appeared providing additional information about the encounter. Users may select encounters in a number of ways, including but not limited to right clicking, double clicking, and hovering over the encounter on the status bar graph. Other methods of interacting with the present invention could also be used, such as but not limited to the use of a touch screen, speech recognition or guidance and portable/tablet/handheld computers. The information summary box  48  preferably displays information pertaining to the encounter, such as but not limited to the type of encounter, the doctor&#39;s name, the patient&#39;s name, the date, the start time of the encounter, and the length of time the encounter has been ongoing. In  FIG. 1 , the information summary box  48  shows that Dr. Joshua Wright is performing a rhinoplasty procedure on patient Phyllis Advent on May. 27, 2004 that started at 10 am and has been ongoing for 95 minutes. Users can also preferably select an encounter and access additional information pertaining to the encounter, to the patient, or to the doctor performing the encounter. For example, a user could select an encounter and access information about the patient&#39;s insurance, billing history, health history, and medication prescriptions. All information contained in the health information system or health care scheduling system can preferably be accessed by selecting an encounter and requesting the information. A request for information could produce a completely configurable report showing the requested information. For example, a user could choose to display the information without private patient information on a large screen visible to everyone in the health care facility.  
         [0037]      FIG. 2  is a sample screen shot illustrating the real-time status system of the present invention in a “real-time only” view showing the real-time status of encounters in the operating rooms of  FIG. 1 .  FIG. 2  shows only the real-time status rows  26  for each of the operating rooms shown in  FIG. 1 . The lightning bolt  28  is displayed in connection with the heading in column  22  to indicate that all of the rows in the column  22  are real-time status rows  26  showing the real-time status of the encounters in each operating room. Using the “real-time only” view, users can easily see the real-time status of the encounters. This view is valuable because the real-time status is the only status that is important to some users. For example, a doctor may know that she is scheduled to perform a procedure at 4 pm in operating room number  1 , and use the real-time only view to see that the encounter now has a real-time start time of 6 pm. The doctor would then know that she does not need to be ready for another two hours.  
         [0038]      FIG. 3  is a sample screen shot illustrating the real-time status system of the present invention in a “scheduled only” view showing the scheduled status of encounters in the operating rooms of  FIG. 1 .  FIG. 3  shows only the scheduled status rows  24  for each of the operating rooms of  FIG. 1 . In addition,  FIG. 3  shows an informational line of text  49  that appeared when a user selected the “Advent, Phyllis” encounter  34 . The option for this “scheduled only” view, while it does not provide real-time status information to the user, is not necessary but is preferred because it provides users with a complete set of viewing options. In addition, although the preferred embodiment includes three views, all three views would not be required to facilitate the present invention, and additional views including other relevant information could also be included. For example, a tabular format view such as a grease board view could also be included. Other views, such as a single room view or single physician view would also be possible. In such views, it would be possible to provide additional levels of detail regarding each encounter associated therewith.  
         [0039]      FIG. 1A  is a sample screen shot illustrating an embodiment of the real-time status system of the present invention in a comparison view showing both the scheduled and the real-time status of encounters for several physicians.  FIG. 1A  is analogous to  FIG. 1 , but shows the real-time status and scheduled status of encounters for physicians in a clinic instead of encounters in a surgical facility. An encounter in a clinic facility could be a patient office visit as shown in  FIG. 1A , thus, the real-time status system can be used to show and track the statuses of all patient office visits in the clinic facility from beginning to end.  FIG. 1A  shows a graphical user interface  16  displaying a window  18  of a health care scheduling system. The window  18  includes a timeline  20  and a column  23  listing the various physicians in a health care clinic. Each physician listed in the column  23  has a first row dedicated to scheduled status  24  and a second row dedicated to real-time status  26 . The real-times status rows  26  include a lightning bolt icon  28  to distinguish the real-time status rows  26  from the scheduled status rows  24 . As previously noted, other methods for distinguishing the real-time status from the scheduled status could also be used.  
         [0040]     The scheduled status for each encounter scheduled for each physician is displayed in each scheduled status row  24  underneath and corresponding to the timeline  20 . The timeline  20  is labeled at each hour 30 of the day and includes tick marks  32  for every 15 minutes. The scheduled status of each encounter is shown as a bar graph beginning at the scheduled start time for the encounter and ending at the scheduled end time for the encounter. The scheduled status row  24  labeled “Dr. Pinderski” shows the scheduled status for several encounters scheduled for Dr. Pinderski. Likewise, the scheduled status row  24  labeled “Dr. Warner” shows the scheduled status of several encounters for Dr. Warner, the scheduled status row  24  labeled “Dr. Sidran” shows the scheduled status of several encounters for Dr. Sidran, the scheduled status row  24  labeled “Dr. Baker” shows the scheduled status of several encounters for Dr. Baker, and the scheduled status row  24  labeled “Dr. Thom” shows the scheduled status of several encounters for Dr. Thom. The scheduled status of each encounter is displayed in a color code unique to the physician responsible for the encounter. The scheduled status of Dr. Pinderski&#39;s encounters are displayed in beige, the scheduled status of Dr. Warner&#39;s encounters are displayed in pink, the scheduled status of Dr. Sidran&#39;s encounters are displayed in light yellow, the scheduled status of Dr. Baker&#39;s encounters are displayed in teal, and the scheduled status of Dr. Thom&#39;s encounters are displayed in blue. As previously described, the color codes used in connection with the present invention can be completely customized and configured by the system administrator or user.  
         [0041]      FIG. 1A  also shows the real-time status for each encounter displayed in each real-time status row  26  immediately below the corresponding scheduled status row  24 . Thus, as shown, the real-time status row  26  for “Dr. Pinderski” is displayed immediately below the scheduled status row  24  for “Dr. Pinderski.” All of the real-time statuses are shown in green to alert the user that the status is a real-time status. Like the comparison view of  FIG. 1 , the comparison view of  FIG. 1A  allows users to easily compare the scheduled status of the encounters to the real-time status of the encounters. For example, a user can compare the real-time status of the “Coleman, Alexis” encounter  56   a  to the scheduled status of the “Coleman, Alexis” encounter  56  and see that the encounter  56   a  actually started later than scheduled and is expected to end later than scheduled, which will also delay the “Yates, Terry” encounter  57   a . A user can also compare the real-time status of the “Haack, Judy” encounter  58   a  with the scheduled status of the “Haack, Judy” encounter  58  to see that the encounter  58   a  started earlier than scheduled, which allowed the next encounter, the “Matthews, Jessica” encounter  59   a , to start earlier than scheduled. As previously noted, users can easily see which encounters are on schedule and which are early or delayed using this comparison view.  
         [0042]      FIG. 1A  also shows the use of various visual cues with the real-time status system of the present invention. In addition to the color codes described above,  FIG. 1A  also shows icons used as visual cues. An ambulance icon  52  is used to indicate an emergency encounter, an open door icon  53  is used to indicate the patient is ready to be discharged, a cross icon  54  is used to indicate the patient is waiting to be seen, and a doctor and nurse icon  55  is used to indicate that the patient is currently being treated. Any icon, color code, or other visual cue can be used to represent any number of different characteristics associated with the encounters, and the real-time status system of the present invention allows users to completely configure and customize the visual cues.  
         [0043]      FIG. 2A  is a sample screen shot illustrating the real-time status system of the present invention in a “real-time only” view showing the real-time status of encounters for the physicians of  FIG. 1A .  FIG. 2A  is analogous to  FIG. 2 , and shows only the real-time status rows  26  for each of the physicians shown in  FIG. 1A .  
         [0044]      FIG. 3A  is a sample screen shot illustrating the real-time status system of the present invention in a “scheduled only” view showing the scheduled status of encounters for the physicians of  FIG. 1A .  FIG. 3A  is analogous to  FIG. 3 , and shows only the scheduled status rows  24  of the physicians shown in  FIG. 1A .  
         [0045]      FIG. 4  is a sample screen shot illustrating the real-time status system of the present invention showing an encounter being performed out of scheduled order.  FIG. 4  shows the comparison view of  FIG. 1 , but further illustrates that the comparison view can be used to easily show a user that an encounter is being performed out of scheduled order. In  FIG. 4 , the scheduled status of the “Bordel, Will” encounter  37  shows that the encounter  37  was scheduled to be performed after the “Andrews, Cecily” encounter  36 . The real-time status of the “Bordel, Will” encounter  37   a , however, shows that the encounter  37   a  was actually performed before the “Andrews, Cecily” encounter  36   a .  FIG. 4  also shows different text in the line of informational text  49 , because the user has selected a different encounter, namely, the “Bordel, Will” encounter  37 .  
         [0046]      FIG. 5  is a sample screen shot illustrating the real-time status system of the present invention showing an emergency encounter being performed that was not first scheduled.  FIG. 5  also shows the comparison view of  FIG. 1 , but further illustrates that the comparison view can be used to easily show a user that an unscheduled encounter is being performed. Unscheduled encounters are typically emergency encounters that were unable to be first scheduled in the health care scheduling system.  FIG. 5  shows the unscheduled “Dormer, Ben” encounter  50   a  being performed between the “Advent, Phyllis” encounter  34   a  and the “Billman, Penelope” encounter  35   a .  FIG. 5  also shows an informational line of text  49  that appeared when a user selected the “Dormer, Ben” encounter  50   a , and a tool tip  48  that appeared when a user hovered over the “Harris, Anne” encounter  39 .  
         [0047]      FIG. 6  is a sample screen shot illustrating another embodiment of the real-time status system of the present invention showing a grease board view. The grease board view can provide the real-time status for encounters in a tabular format. In other words, the grease board view can display the information calculated using the same logic as is used to display information in a graphical format.  FIG. 6  shows a graphical user interface  16  displaying a window  18  of a health care scheduling system  12 . The window  18  includes a table  60  showing columns of information regarding the encounters in the operating rooms of  FIG. 1 . The table  60  includes columns for encounter priority  62 , operating room  63 , projected (or real-time) start time  64 , projected (or real-time) end time  65 , patient name  66 , surgical case number  67 , primary surgeon name  68 , procedure name  69 , and progress status  70 . The table  60  also includes a row for each encounter in the health care facility. In  FIG. 6 , the real-time status is shown for each of the encounters of  FIG. 1 . Thus, there is a row for the “Advent, Phyllis” encounter  34   a , a row for the “Billman, Penelope” encounter  35   a , a row for the “Andrews, Cecily” encounter  36   a , a row for the “Bordel, Will” encounter  37   a , a row for the “Quaid, Connie” encounter  38   a , a row for the “Harris, Anne” encounter  39   a , a row for the “Gep, Bob” encounter  40   a , a row for the “Lassel, Tina” encounter  41   a , a row for the “Bilmore, Deacon” encounter  42   a , and a row for the “Weese, Charles” encounter  43   a  The projected start time column  64  displays the real-time start time for each encounter, and the projected end time column  65  displays the real-time end time for each encounter. For example, the real-time start time for the “Advent, Phyllis” encounter  34   a  is 10:15, and the real-time end time for that encounter  34   a  is 11:50.  
         [0048]     The grease board view shown in  FIG. 6  uses the same color codes and icons as the comparison view in  FIG. 1 . The grease board view in  FIG. 6  includes a legend  61 . The legend  61  shows the color purple  71  to indicate a patient is in the operating room undergoing a surgical procedure, the color light green  72  to indicate a patient has arrived at the PACU, the color green  73  to indicate a patient has been discharged from the PACU, the color light pink  74  to indicate a patient has arrived in the operating room, and the color dark pink  75  to indicate a patient is in the pre-op area. The down arrow icon  46  and the exclamation point icon  47  are also used, and displayed in the priority column  62 . Although the grease board view shown in  FIG. 6  corresponds to the graphical format views of  FIGS. 1, 2  and  3 , the present invention could include only a grease board view for displaying the real-time status of encounters.  
         [0049]      FIG. 7  is a sample screen shot illustrating a color configuration screen for selecting the colors displayed in the real-time status system of the present invention.  FIG. 7  shows a graphical user interface  16  displaying a window  18  of a health care scheduling system. The window  18  includes a timeline  20  and a column  22  listing various operating rooms. The scheduled status of each of the encounters is displayed for each operating room. An edit window  76  appeared when a user selected the “schedule colors” button  77  on the window  18 . The edit window  76  includes selection boxes for the colors that will be displayed for the text and background of various types of information displayed in the window  18 .  FIG. 7  shows selection boxes for the text and background for surgeries  78 ,  78   a , blocks of available time  79 ,  79   a , unavailable time  80 ,  80   a  and hold time  81 ,  81   a  displayed on the window  18 . In addition, the edit window  76  includes selection boxes for the color of a border shown around selected information displayed in the window  18 .  FIG. 7  shows selection boxes for the light and dark border colors around selected surgeries  82 ,  82   a , selected open times  83 ,  83   a , and selected open blocks of time  84 ,  84   a . The colors selected in the edit window  76  are reflected in the display shown in the window  18  of  FIG. 7 . The gall bladder  85 , the heart bypass  86 , the pacemaker insertion  87 , the heart biopsy  88 , and the burn treatment  89  surgeries are shown with a yellow background and black text, blocks of available time  90  are shown in a teal background with white text, unavailable time  91  is shown in a red background with white text, on hold time slots  92  are shown in a gray background with white text, and the selected open block of time  93  is shown with a green and yellow border. The colors are completely configurable and customizable. Once a user has selected the desired colors, the user can select the “Accept” button  94  to accept the color choices, or a user can select the “Cancel” button  95  to cancel the color choices.  FIG. 7  shows the edit screen for the colors associated with the scheduled status of the encounters, but the present invention allows a user or system administrator to choose the colors associated with the real-time status of the encounters, as well as the general display colors. Users could choose those colors in an analogous fashion.  
         [0050]      FIG. 8  is a sample screen shot illustrating an embodiment of an encounter tracking log for inputting information for various encounters of the present invention.  FIG. 8  shows a graphical user interface  16  displaying a window  18  of a health care scheduling system. The window  18  shows a timeline  20  and a column  22  of various operating rooms. The column  22  includes a scheduled status row  24  and a real-time status row  26  for each of the listed operating rooms.  FIG. 8  also shows a tracking window  96  that appeared when a user requested access to the tracking log displayed in the tracking window  96  for a particular encounter. Users can request access to the tracking log in any number of ways, including but not limited to selecting an encounter from the window  18 . The tracking log includes a table  98  having a column for the name  100  of the event, the “Time In”  101  (the time the event actually started), the “Time Out”  102  (the time the event actually ended), and the “Time Elapsed”  103  (the time elapsed between the event&#39;s actual start and end times).  FIG. 8  shows rows for “Room Set-up Start”  104 , “Patient-Operating Room”  105 , “Room Clean-up Start”  106  and “Room Clean-up Finish”  107 . In each row a user can enter the time the event actually started in the “Time In” column  101 , and the time the event actually ended in the “Time Out” column  102 . In the “Room Clean-up Start” row  104  shown in  FIG. 8 , for example, a user has entered an actual start time of 10:15 and an actual end time of 10:30. Alternatively, the user can simply check the corresponding check box  108  in the “Time In” or “Time Out” columns  101 ,  102  to indicate that the event has actually started or ended. The present invention can then automatically fill in the actual start or end time with the time corresponding to the time the check box was checked. Other features for allowing users to quickly enter the actual data can also be used, including but not limited to the use of short cuts such as the letter “n” to indicate a time of “now” or the current time. The tracking log of  FIG. 8  is configured to allow a user to view particular event types separately.  FIG. 8 , for instance, shows “IntraOp” events in a drop down window  114  to indicate that IntraOp event types are currently displayed. A user could use the drop down window  114  to choose to view other event types for a particular encounter, such as “PreOp” or “PostOp” events.  FIG. 8  also includes a “Projected Times” box for displaying the projected start time  109 , the projected end time  110 , and the estimated end time  111 . Using the tracking log shown in  FIG. 8 , the user can enter the estimated end time  111 , but the real-time status system calculates the projected (or real-time) start and end times  109 ,  110 . Once a user has entered the desired information into the tracking log, the user can select the “Accept” button  112  to accept or input the information, or a user can select the “Cancel” button  113  to cancel the entered information. The tracking log is a tool for collecting actual tracking information including actual start and end times for encounters and events within encounters. The tracking log is completely customizable and configurable by the user or system administrator, and does not need to have the specific configuration shown in  FIG. 8 .  
         [0051]      FIG. 9  is a sample screen shot illustrating an embodiment of a configuration screen for configuring the encounter tracking log of the present invention.  FIG. 9  shows a graphical user interface  16  displaying a window  18  of a health care scheduling system. A tracking configuration window  15  is also displayed in  FIG. 9 . The configuration window  115  includes a table with columns for the tracking event name  116 , the event type  117 , the status  118  associated with the event, and the color  119  associated with the event. The rows of the table contain a list of events that will be used to track a particular encounter. The user can add events to the list by selecting the “Insert Row” button  120 , or delete events from the list by selecting the “Delete Row” button  121 . The user can also choose which event will signal that the encounter is complete by entering that event into the “Completed Case Status” box  122 . For example, the “Completed Case Status” box  122  in  FIG. 9  shows that a user has selected the event named “Discharge from PACU” to signal that the encounter is complete. Thus, the actual end time for the encounter will be the actual end time for the “Discharge from PACU” event within the encounter. The user can also choose the status to associate with a patient at check-in by entering that status in the “status at check-in” box  124 , and the event to associate with a patient at check-in by entering that status in the “event at check-in” box  123 . The user can further choose which colors are associated with particular encounter statuses by entering those colors into the “Case Status” box  133 .  FIG. 9  also allows a user to choose timing events for the encounter. The set-up start timing event is shown as “Room Set-up Start” in box  125 , the set-up end timing event is shown as “Patient-Operating Room” in box  126 , the clean up start timing event is shown as “Patient-PACU” in box  127  and the clean up end timing event is shown as “Room Clean-up Finish” in box  128 . Thus, the tracking log will start timing the encounter set up when an actual start time is entered for the “Room Set-up Start” event and will stop timing the encounter set-up when an actual start time is entered in the tracking log for the patient&#39;s arrival in the operating room, shown as the “Patient-Operating Room” event. The user can use the “Cancel” button  129  to cancel her entries, the “Back” button  130  to go to the previous configuration screen, the “Next” button  131  to go to the next screen, and the “Accept” button  132  accept or input her entries. A user is able to select or deselect any encounter events, including events not shown in  FIG. 9 , for tracking purposes. The specific configuration screen shown in  FIG. 9  is one way in which the user could choose the tracking events, and other methods are certainly possible.  
         [0052]      FIG. 10  is a flow diagram illustrating an example of logic used to calculate the real-time start time and the real-time end time for a single encounter using the real-time status system of the present invention. To calculate and update the real-time information, the system of the present invention stores real-time information for each encounter including a real-time start time and a real-time end time. Depending on the status of the encounter, the real-time start time and the real-time end time for the encounter are either actual times as recorded in the encounter tracking log, or estimated times calculated as described below. For instance, if an encounter has started but not yet ended, the real-time start time for the encounter will correspond to the actual start time recorded in the tracking log for the encounter, but the real-time end time will be an estimated end time for the encounter calculated as described below. The real-time start time and the real-time end time for each encounter are displayed on the graphical user interface as the real-time status of the encounter.  
         [0053]     To begin recalculating or updating the real-time information for an encounter  200 , the real-time status system of the present invention first determines whether the encounter has just been scheduled  201 , whether the encounter has had a room change  202 , and whether the encounter has been cancelled  203  since the last time the real-time information for the encounter was updated or refreshed. If an encounter B has been scheduled  201   a  since the last update or refresh, the system retrieves the real-time end time of the previously scheduled encounter A for later use  204 . If not  201   b , the system moves on to determine whether the encounter room has been changed  202 . If the encounter room has been changed from a previous room to a new room  202   a , the system saves the new room information  206 , loads the real-time information from the previous room  205 , and updates the real-time information from the previous room to reflect the room change  207 . If the encounter room has not been changed  202   b , the system moves on to determine whether the encounter has been cancelled  203 . If so  203   a , the system removes the real-time information for that encounter from the system  208 , and moves on to update the room refresh time  209 . If the encounter has not been cancelled  203   b , the system recalculates the real-time information for the encounter  210  as described below.  
         [0054]     To recalculate the real-time information for an encounter  210 , the real-time status system first loads the information stored in the tracking log for the encounter  211 . The system then determines whether the encounter has started  212 , i.e., if the information from the tracking log contains an actual encounter start time. If so  212   a , the real-time start time is then set to the actual encounter start time  213 . The system then determines whether the encounter has ended  214 , i.e., if the information from the tracking log contains an actual encounter end time. If so  214   a , the real-time end time is set to the actual encounter end time  215 , and the system moves on to compare the new real-time start and end times with the previously stored real-time start and end times  216 . If the encounter has not ended  214   b , the system determines whether any events have ended  217 , i.e., if the information from the tracking log contains any actual event end times. If so  217   a , the system then updates the real-time end time based on the remaining events  218 . For example, if there are two events remaining, and those procedures typically take 30 minutes each to complete, the system will update the real-time end time to account for the hour of remaining events. Once the real-time end time is updated  218 , the system then moves on to compare the new real-time start and end times with the previously stored real-time start and end times  216 . If no events have ended  217   b , the system moves on to compare the new real-time start and end times with the previously stored real-time start and end times  216 . If an encounter has not started  212   b , the real-time start time is then set to the scheduled encounter start time  219 , preferably stored in the schedule for the encounter. The system then moves on to compare the new real-time start time for the current encounter B with the real-time end time of the previous encounter A  220 . If the real-time end time for the previous encounter A is earlier than the new real-time start time for the current encounter B  220   b , the system moves on to compare the new real-time start and end times for the current encounter B with the previously stored real-time start and end times for the current encounter B  216 . If the real-time end time for the previous encounter A is later than the new real-time start time for the current encounter B  220   a , the real-time start time of the current encounter B is updated and set to the real-time end time of the previous encounter A  221 , and the system moves on to compare the new real-time start and end times for the current encounter B with the previously stored real-time start and end times for the current encounter B  216 . If the new real-time start and end times are different than the previously stored real-time start and end times  216   a , the system updates the real-time information with the new real-time start and end times  222 ; if the new real-time start and end times are not different than the previously stored real-time start and end times  216   b , the system determines that an update is not necessary and moves on to update the room refresh time  209 . Once the real-time start and end times have been updated  222 , or the system determines that no update is necessary  216   b , the system updates the room refresh time to the current time to represent the last time the room was updated  209 . The system then compares the updated room refresh time to the new real-time start time for the encounter  223 . If the updated room refresh time is later than the new real-time start time for the encounter B  223   a , the system will store the updated room refresh time  224 , and then the encounter update loop is complete  225 . If the updated room refresh time is not later than the new real-time start time for the encounter B  223   b , then the encounter update is complete  225 .  
         [0055]      FIG. 11  is a flow diagram illustrating an example of logic used to calculate the real-time start and end times for all encounters in a single operating room using the present invention. In updating the display for an entire room  230 , the system stores a maximum end time, which the system initially sets to the current time  231 . The system then determines whether a refresh is needed  232 . Preferably, the system refreshes when a refresh is requested, but only refreshes the data that is old enough, that is, data that has not been updated in for example the last minute. The system could, however, refresh all the data whenever a request is made, or could refresh all the data automatically at certain time intervals, for example, the system could refresh automatically once every minute. In addition, the system could use logic that includes a modification factor to prevent all of the data for coming up for refresh at the same time, as it is inefficient for the system to refresh all the data at one time. If a refresh is not needed  232   b , the update is completed  259 . If a refresh is needed  232   a , the system then loops through the earlier encounters  233 , i.e., the encounters that have real-time start times, calculated as described above and shown in  FIG. 10 , earlier than the current time. The system downloads the encounter tracking information from the tracking log for each encounter in the room being updated  234 , and checks to see if any encounters have started  235 . Encounters that have not yet started  235   b  are stored in an undone encounter structure for later use  236 . For encounters that have started  235   a , the system then determines whether the encounter has ended  237 . If so  237   a , the system determines whether the real-time end time for the encounter is later than the maximum end time  239 . If not  239   b , the system completes the loop for that encounter. If so  239   a , the system updates the maximum end time to match the real-time end time for that encounter  240 , and completes the loop for that encounter. If an encounter has started but not yet ended  237   b , the system determines whether the current time is later than the real-time end time for the encounter  238 . If so  238   a , the system updates the real-time end time for the encounter to match the current time  241 , and then checks to see if the real-time end time is later than the maximum end time  239 . If the real-time end time is later than the maximum end time  239   a , the system updates the maximum end time  240 . If the current time is not later than the real-time end time for the encounter  238   b , the system determines whether the real-time end time is later than the maximum end time  239  and if so  239   a , updates the maximum end time accordingly  240 . The system repeats the loop through the earlier encounters  233  until all of the earlier encounters have been updated.  
         [0056]     Once the system has looped through all the earlier encounters  233 , the system loops through current stand alone tracking logs  242 . Stand alone tracking logs are tracking logs for encounters that were not first scheduled, such as emergency encounters. In some health care settings, it is not necessary to have stand alone tracking logs. For example, in many clinical settings there are rarely emergency encounters, or encounters that are so critical that there would not be enough time to add them to the schedule first. In that encounter, the system would skip the loop through the stand alone tracking logs and loop through future scheduled encounters once the loop through the earlier encounters is complete. The loop through the stand alone tracking logs, as shown, is analogous to the loop through the earlier encounters, with the only difference being that the system does not need to first check to see if the encounter has started because there would not be a stand alone tracking log if the encounter had not yet started. Thus, as shown, the system downloads the encounter tracking information from the stand alone tracking logs in the room being updated  243 , and checks to see if any of the encounters have ended  244 . If so  244   a , the system determines whether the real-time end time for the encounter is later than the maximum end time  245 . If not  245   b , the system completes the loop for that encounter. If so  245   a , the system updates the maximum end time to match the real-time end time for that encounter  246 , and completes the loop for that encounter. If an encounter not yet ended  244   b , the system determines whether the current time is later than the real-time end time for the encounter  247 . If so  247   a , the system updates the real-time end time for the encounter to match the current time  248 , and then checks to see if the real-time end time is later than the maximum end time  245 . If the real-time end time is later than the maximum end time  245   a , the system updates the maximum end time  246 , and if the real-time end time is not later than the maximum end time  245   b , the loop is completed. If the current time is not later than the real-time end time for the encounter  247   b , the system determines whether the real-time end time is later than the maximum end time  245  and if so  245   a , updates the maximum end time accordingly  246 , and if not  245 b, the loop is completed. The system repeats the loop through the stand alone tracking logs  242  until all the encounters in the stand alone tracking logs have been updated.  
         [0057]     Once the loop through the stand alone tracking logs  242 , if required, is complete, the system then loops through the future scheduled encounters  249 , i.e., the encounters that have a real-time start time that is later than the current time. The system first loads the tracking log information for the future scheduled encounters for the room being updated  250 . The system then determines whether the maximum end time plus the undone time—or the amount of time an encounter was originally scheduled for—is earlier than the real-time start time  251 . If not  251   b , the encounter is stored in the undone encounters structure  252 , and if so  251   a , the loop is complete for that encounter. The loop  249  is repeated until all future scheduled encounters for the operating room have been updated.  
         [0058]     Once the loop through the future scheduled encounters  249  is complete for all future scheduled encounters, the system loops through the undone encounters in the undone encounter structure  253  for the room being updated. Undone encounters are earlier encounters that have not yet started and future encounters that have a real-time start time that is later than the maximum end time plus the undone time. The system first determines whether the scheduled start time is later than the maximum end time  254  and if not  254   b , the system pushes the encounter into the future based on the maximum end time  255 . For example, if an encounter was scheduled to start at 4 pm, but the maximum end time is 5 pm, the encounter will be pushed out on the real-time status bar graph, having a real-time start time of 5 pm and a real-time end time one hour later than the previously stored real-time end time. If the scheduled start time is later than the maximum end time  254   a , the system updates the maximum end time to match the real-time end time  256  and then pushes the encounter into the future based on the maximum end time  255 . On each loop through the undone encounters, the maximum end time is updated to the real-time end time for the undone encounter  257 . Once the loop  253  is complete for all undone encounters, the room update is complete  258 .  
         [0059]     Although example logic for updating the status of rooms and encounters is shown in  FIGS. 10 and 11 , the logic shown is not particular to the present invention. Other logic could be used, steps could be added or deleted from the logic shown, or the system could use other variables to calculate the real-time status. For example, the real-time status system of the present invention could also calculate the real-time status of a specific room based not only on the status of encounters occurring in that specific room, but also based on the availability of resources or problems that occur in other rooms that may affect the real-time status of the specific room. Thus, if a doctor is scheduled to perform a procedure in Operating Room number  1  at 4 pm, but that doctor is still performing a procedure in a different location that is scheduled to last past 4 pm, the real-time status system could update the real-time status of Operating Room number  1  accordingly. As another example, the system could also include automatic features, such as automatically entering a default actual end time for a previous encounter if the next encounter in that room has been started before an actual end time was entered for the previous encounter. Further, although  FIGS. 10 and 11  and the foregoing description refer to encounters tracked by rooms, analogous logic could apply to encounters that are tracked by physician or other tracking criteria. For example, analogous logic would be used to generate the real-time status for each physician in a clinical setting, such as the real-time status shown in  FIGS. 1A, 2A , and  3 A.  
         [0060]     Many other features could be used in connection with the real-time status system of the present invention. For instance, delays shown on the real-time status system could also trigger other actions. As soon as a real-time end time for a particular encounter is later than the scheduled end time, the system could send an email, page or other message to the charge nurse or the reception desk so that the schedules or other resources could be modified accordingly. In addition, real-time information could be used in many other health care scheduling system functions. When a user searches for open times, for example, the real-time information could be used to prevent the user from scheduling a new encounter in what looks like an open time slot on the schedule, but is really not an open time slot because the earlier cases had been delayed. The real-time information could also be used on staffing schedules, to let staff know when encounters for which they are scheduled are actually going to start.  
         [0061]     While the invention has been described with reference to preferred embodiments, those skilled in the art will appreciate that certain substitutions, alterations and omissions may be made to the embodiments without departing from the spirit of the invention. Accordingly, the foregoing description is meant to be exemplary only, and should not limit the scope of the invention as set forth in the following claims.