Nothing Special   »   [go: up one dir, main page]

GB2354853A - Computer modelling of health care procedures - Google Patents

Computer modelling of health care procedures Download PDF

Info

Publication number
GB2354853A
GB2354853A GB0013811A GB0013811A GB2354853A GB 2354853 A GB2354853 A GB 2354853A GB 0013811 A GB0013811 A GB 0013811A GB 0013811 A GB0013811 A GB 0013811A GB 2354853 A GB2354853 A GB 2354853A
Authority
GB
United Kingdom
Prior art keywords
task
pathway
encounter
tasks
cost
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0013811A
Other versions
GB0013811D0 (en
Inventor
Jay Ferguson
Seaforth M Lyle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CURAPATH SYSTEMS Inc
Original Assignee
CURAPATH SYSTEMS Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CURAPATH SYSTEMS Inc filed Critical CURAPATH SYSTEMS Inc
Publication of GB0013811D0 publication Critical patent/GB0013811D0/en
Publication of GB2354853A publication Critical patent/GB2354853A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/40ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to mechanical, radiation or invasive therapies, e.g. surgery, laser therapy, dialysis or acupuncture
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00ICT specially adapted for the handling or processing of medical references
    • G16H70/20ICT specially adapted for the handling or processing of medical references relating to practices or guidelines

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Surgery (AREA)
  • Urology & Nephrology (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Bioethics (AREA)
  • Biomedical Technology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

A method of modelling health care procedures comprises the steps of storing data relating to encounters, tasks and resources, incorporating then into a clinical pathway and displaying the resultant pathway on a screen. Cost may be entered for each task, encounter or resource in a pathway and used to determine a cost for the full pathway. Costs may also be determined on a duration basis for reusable items in the pathway. The data for a task may include a number of subtasks. Data indicating the sequential nature of the procedure is also stored, preferably in a series of steps tables (Fig 20-22) and indicates the order of a task and if a task is undertaken sequentially or in parallel with another. The data is presented in a number of windows. A first window 12 shows the pathway as a collection of individual encounters. When an encounter is highlighted details of the encounter 66 are shown in a second window 14 together with a display in a third area of the screen (16, Fig 1) indicating a series of sub tasks 88-108 or resources to be undertaken pertaining to that encounter.

Description

2354853 METHOD FOR PERFORMING ACTIVITY BASED COSTING FOR HEALTH CARE
PROVIDER FAciLITIES This invention is related to cost analysis and accounting for hospitals and other health care facilities.
Activity based costing has been extensively used f or analyzing manufacturing operations and is an effective method of discovering the true costs of operations and managing those costs. To be effective, costbased accounting requires that all the significant activities of an organization be carefully defined in terms of the operations required and the resources consumed by the activity.
In real life hospital operations, this frequently requires thousands of data points. This database is crucial for an accurate analysis and typically varies greatly between organizations, even those which are performing similar functions. Currently available methods of collecting and analyzing this data requires significant familiarity with cost and other accounting principle which health care workers and administrators typically do not have. Furthermore, not many accountants are familiar enough with the details of hospital operations to generate this database. Thus, it is desirable to have a method for allowing heath care workers to easily and conveniently generate the data required for cost based accounting in hospitals and other health care facilities.
2 The present invention provides a graphical interface and modeling capability that links all the activities of a hospital to the flow of a patient through the many activities and procedures that are encountered during a hospital visit or stay. The manner in which the various activities and resources required for each particular activity correspond closely to their actual occurrence in the hospital environment. Each type of procedure that the hospital performs is represented by a pathway which 3-0 reflects all of the activities involving the patient and all of the resources consumed in treating the patient. The graphical nature of the interface and the intuitive representation of the pathway result in a modeling tool that may be easily used by clinical personnel not familiar with cost based accounting principles to create accurate models of hospital procedures.
The advantages and operation of the present invention are more fully described in the following description of the preferred embodiment and by reference to the drawings, of which:
Fig. 1 shows the main display for the pathway modeler component of the present invention; Figs. 2 and 3 illustrate the hierarchal tree structure that is used to organize items in the library module; Fig. 4 shows the main display during the examination of an exemplary pathway; Fig. 5 shows a more complicated pathway having several encounters; Figs. 6, 7, and 8, show detail displays for encounters and tasks; 3 Figs. 9A to 9G show a printout of a pathway of typical complexity; Fig. 10 shows the top level library window tree for resources; Fig. 11 shows a screen displaying the results of a name search; Fig. 12 shows a window for entering information about a resource; Fig. 13 shows a window that may be used to search for a particular procedure; Figs. 14-22 show the format of data storage in the pathway library; Figs. 23-24 are flow diagrams showing the methods by which the pathways are constructed and displayed based on the pathway data stored in the pathway library; Figs. 25 and 26 show how the data from modeled pathways in a hospital can be used to estimated the resource costs for unmodeled pathways; and Fig. 27 shows a table that can be used to calculate a variance value from pathway data that is useful in identifying potential problem areas.
Before describing the structure and operation of the present invention, it will be helpful to describe the various components that are used to model the various procedure that the hospital or health care facility carries out. In the following description, the operation of the present invention will be described in terms of hospital procedures for the sake of brevity, but it should be understood that the invention is applicable to many other types of health care facilities in addition to hospitals.
4 The invention consists of three major modules: a pathway modeler; a library that contains data representing the various pathways and the tasks that make up the pathways, and a financial analyzer.
The most important module is the pathway modeler. It provides a quick and intuitive way of entering information that is stored in the library. By using the pathway modeler, clinical personnel can quickly and easily prepare complex database representations of the different procedures performed by the hospital. Administrative personnel may use the modeler to identify the procedures that are key cost centers and also may perform "what-if" analysis to evaluate the impact on total costs of changes in procedures and costing.
The library contains data that represents the details of procedures carried out by the hospital and the costs associated with each procedure. Typically, the library is initially provided with data representative of typical pathway and task data based on data from other hospitals, and the pathway modeler is used to modify this data so that it accurately represents the procedures and costs of the subject hospital.
The financial analyzer uses the data in the library to provide financial statements that link the costs of the hospital to individual activities so that the financial effects of changes in the hospital operations can be quickly and accurately analyzed.
The described embodiment of the invention is implemented in software that may be easily run on a so- called personal computer or PC. In the description below, the software is described and shown as it may be implemented on a PC running the Windows operating system. It should be appreciated that the invention may be easily implemented in a manner to run on other types of computers and operating systems by programmers of ordinary skill after reading the description of the invention below.
Before explaining the user interface, it will be helpful to briefly summarize the way in which hospital procedures are modeled. The model of the hospital procedures is made up of four basic types of objects: pathways, encounters, tasks, and resources. The first object type is a patient pathway, which represents the sequence of activities that occur as a patient physically moves through the hospital and is subject to various procedures. A pathway could represent the activities that take place when a person is admitted for treatment of a minor cut or other trauma, or it could represent all the activities that occur in a heart transplant procedure. Associated with each pathway is a unique name, a number or code (such as a DRG number), a list of the all the encounters that make up the pathway, and the duration and cost of the pathway.
A pathway is composed of one or more encounters. An encounter represents all the activities that take place in a single location in the hospital. Encounters are made up of one or more tasks. Thus f or a minor trauma, there might be two encounters: an admitting procedure in the emergency admitting room and treatment activities in a treatment room, while a transplant operation would include a great many encounters. It is important to note that an encounter 6 is always associated with a particular location in the hospital. Each encounter has associated with it the name of the encounter, the location in the hospital where it the encounter takes place, a list of all the tasks that make up the encounter, the duration of the encounter, and the cost of the encounter.
Encounters are made up of individual tasks. Tasks represent the resources that are required to carry out an activity. Resources are explained in more detail below.
A task may be the resource itself or may be a collection of other tasks, or subtasks, which are themselves resources. For example, a task could be a medicinal dose, which would have the cost of the medicine associated with it, or a task could be a sutering procedure, which would be made up of subtasks such as the cost of the sutering kit, the time required of the physician doing the procedure, and so forth. There may be several levels of subtasks, but ultimately, at the lowest level, a task is made up of one or more resources.
It should be noted that encounters and tasks composed of subtasks are both collections of tasks. The difference between a task with subtasks and an encounter is that an encounter always has a location associated with it, while a task does not. The location represents a facility, such as an operating room, which has a cost per hour. Thus the cost of an encounter is the cost of all included tasks plus the hourly cost of the associated facility times the duration of the encounter.
There are five categories of resources: facilities, equipment, labor, supplies, and drugs; and these five 7 categories are divided into two main types: reusable and non-reusable. Facilities, equipment, and labor are all reusable resources, and supplies and drugs are nonreusable. Each of the five different kinds of resources that make up tasks have a name and a cost associated with them. Additionally, reusable resources have an associated time value, or duration.
The relationship of pathways, encounters, tasks, and resources can be more easily understood by an explanation of the graphical interface of the present invention which allows a user to quickly and easily model the various procedures of a hospital or other health care facility.
Fig. 1 shows the main screen 10 of the pathway modeler module. This screen includes three main sections. The operation of these sections will be described in detail below, but a summary of their functions will be helpful here. In the upper left-hand portion of the screen is the library window 12. The library window allows a user to select a particular object, such as a pathway or a resource, from all the objects in the database. In the upper right-hand portion of the screen is the detail window 14. This window is used to view and change the different values and parameters associated with each of the various types of objects. The bottom half of the screen is the pathway viewer which allows a user to see and modify the encounters and tasks that make up a pathway.
The main screen will typically include other buttons and controls which are typical to the computer system with which the invention is used. For example, by clicking and dragging resizing bars 18 and 20, a use may change the 8 relative sizes of the dif f erent sections of the main screen 10. Similarly, buttons 22, 24, 26, 28, 30, and 32 allow a user to perform various functions such as cutting, deleting, saving, printing, getting help, or exiting the program. A button 34 allows the user to select either global or local mode when changes are made, as described in detail below. In the described embodiment, the library and pathway viewer sections have controls 38 which allow a user to make the library tree and a displayed pathway larger and 3-0 smaller, since these items are frequently too big to view in their entirety. Scroll bars 36 may be provided for windows whose content may exceed the size of the viewable portion of each section. other controls may be provided for as needed, such as additional selection controls when a screen is sized too small to show everything. Alternately, the various functions may be accessed from a menu-oriented interface without departing from the invention.
The library window 12 allows a user to locate a particular pathway, encounter, task, or resource so that it may be viewed or modified. A series of buttons 40, 42, 44, and 46 are used to select which of these f our types of objects will be shown in the library screen 12. In the present invention, each of these objects is stored in a logical ly-arranged, hierarchical tree so that a user who does not know the name of the desired object can quickly find a particular item by going down the tree. In Fig. 1, pathways have been selected for viewing in the library and detail windows, and the library tree shows the top level "Pathways" box 52. Following this box are three 9 subordinate branches denoted by boxes 54, 56, and 58, marked with the type of pathways contained in that box, for example, "Out-patient Pathways" in box 58.
The library screen has two types of boxes.
Categorical boxes are used to organize the library and generally have further branches. object boxes are at the ends of branches and denote individual pathways in the pathway screen shown in Fig. 2. The library tree displays for encounters, tasks, and resources are similarly organized. Categorical boxes are graphically distinguished from object boxes which are end points and represent a particular pathway. Thus, box 60 marked IIER Out Patient" has further branches as is denoted by its grey color, while box 62 represents a particular pathway "PreNatal Care" denoted by its white color.
The library window 12 has a level control 50 that allows a user to expand and contract the number of levels shown f or the pathway tree. For example, in Fig. 3 the pathway tree of Fig. 2 is expanded to show two levels of the pathway tree, which shows that the branch 60 is composed of two pathways 64 and 66. The total number of pathways may be very large, typically in the hundreds, with many of the pathway branches having much deeper tree structure than is shown in Fig. 3, and the ability to control both the size and the number of levels displayed in the pathway tree is a helpful f eature f or a user.
To examine a particular pathway, a user would select the desired pathway, such as by clicking on it with a mouse. After a particular pathway is selected,, the pathway viewer portion of the screen 16 will display the various encounters and tasks that make up the pathway. Fig. 4 shows the display that would result when the pathway 66 is selected. The pathway shown in Fig. 4 represents an the procedures that occur during an emergency room visit by a patient with depression. This pathway is relatively simple, including only a single encounter, but it will be helpful in visualizing the various options available to a user in examining a pathway before going to more complicated pathways.
In Fig. 4, box 66 has been selected, and the detail window 14 gives information on this pathway. The topmost item in the window is the label "pathway" 67, which indicates that the window is showing details of a pathway. The name of the pathway "Depression" is given in box 68.
When a new pathway is created, as described in more detail below, it must be given a unique name, and this name is displayed in box 68. Immediately above box 68 is the name of the subcategory of the pathway, in this case IIER OutPatient" from box 60. In box 72, a code associated with the pathway may be displayed, such as a DRG number. The total cost to the hospital for pathway is shown in box 74. This cost is determined by adding the cost of all of the resources that are used in the pathway. The total duration of the pathway is shown in box 76. The manner in which the total cost and duration of pathways is determined is described below.
A resources window 80 shows the resources that are associated with the pathway. Two check boxes 77 and 78 control the format of the resource window. Normally, the resources window lists only the resource names, as shown in 11 Fig. 4. Checking the "Details" box 78 lists additional details of each of the individual resources, including quantity used, cost, and duration if any. An example of this type of detail display is shown in Fig. 7.
Normally, the resources window only lists the resources directly associated with the -particular pathway, encounter, or task being detailed but does not include resources that are part of included tasks or subtasks. The "Show All" check box 77 when checked causes the resources window to show all resources used, including resources in tasks and subtasks.
Pathways and encounters may or may not have resources directly associated with them. For example, in the Depression pathway shown in Fig. 4, there are no resources directly associated with the pathway, and the resources screen would be empty with the Show All box 77 unchecked.
When box 77 is checked, all the resources included in each of the tasks making up the pathway are listed, as shown in Fig. 4, which shows all the resources associated with tasks 90 through 110 that make up the displayed pathway 82.
Similarly, the ER Psychiatric-OP encounter shown in Fig. 6 has no resources directly associated with it, and the resources screen in detail window 14 is empty, since the Show All box 77 is unchecked. An example of an encounter that does have resources directly associated with it is shown in Fig. 7 which shows the detail window f or the ER Arrival Cardiac-1 encounter 120 from Fig. 5. Fig. 7 shows that this encounter has emergency equipment directly associated with the encounter which is not part of the tasks that make up the encounter.
12 As explained above, a pathway is composed of one or more encounters, and encounters are composed of one or more tasks. Additionally, an encounter is associated with a physical location in the hospital, and it will include tasks that comprise all the procedures that take place in that location. In the present invention, the pathway window identifies pathways, encounters, and tasks that are composed of subtasks (sometimes called super-tasks) by frames in the shape of a sideway 11L11 made of lines on the upper and left-hand sides. Thus, in Fig. 4, the Depression pathway is identified in the pathway viewer window 16 by the pathway name at 84 and the frame made up of lines 82. In this pathway, there is only one encounter. This encounter is named IIER Psychiatric-OP11 at 86 and is denoted by the f rame 88. The tasks that make up the encounter are shown as closed boxes and include the tasks 90 through 106 in Fig. 4. Individual tasks may be independent tasks, as is the case for tasks 90-104. Alternatively, tasks may include other tasks. An example of this is shown by the "Discharge Psychiatric Outpatient" task 110, which is denoted by a frame 110 composed of two independent tasks 106 and 108. As will become more clear below, having tasks that are collections of other tasks allows procedures that are composed of multiple tasks and that are performed in several different encounters to be easily used and/or modified when pathways are created and edited.
Fig. 5 shows a more complicated pathway "Chest Pain ER Visit." This pathway is composed of four encounters: IIER Arrival Cardiac-111 which would take place in the emergency room and includes the tasks within frame 120; "Intermediate 13 Stay Chest Pain" which would take place in a patient room, shown in frame 122; "Nuclear Medicine" which would take place in the radiology room and is shown by frame 124; and finally the "Discharge" encounter, which would take place in the patient room. This pathway also illustrates how the pathway viewer can give a time line along the top of the pathway frame 128. Thus the first encounter for admission and evaluation requires 1 hour and 24 minutes, as shown at 130. After a one day stay, the total duration is 1 day, I hour, 24 minutes, as shown at 132.
Tasks in an encounter may take place either sequentially or in parallel. Sequential tasks are those which must be performed in a particular order and are represented in a pathway by sets of horizontally arranged tasks. Parallel tasks are tasks that may be performed simultaneously and are located above and below other tasks or sets of sequential tasks. For example, in Fig. 4, the Draw Blood task 92 must be performed before the CBC blood test task 98 can be performed. Similarly, the top task line in Fig. 4 shows the patient being admitted 90, then given a medical evaluation 96 followed by a psychiatric evaluation 100. The patient is then treated 104 and discharged 110. Parallel tasks may be performed at the same time. For 25 example, in Fig. 4, the laboratory tests of tasks 92, 98, and 102 can take place at the same time as the above described admission and treatment sequence. Similarly, the administrative work represented by the continuing case management task 94 may take place in parallel with the other two task lines.
14 Thus, the arrangement of the tasks in an encounter graphically represents the actual order in which these tasks are performed. In determining the total duration of an encounter, the time for each sequential task in the longest sequential task line is the minimum time for the encounter. However, a longer time may be designated by a user when appropriate. For example, medical evaluation in an ER examining room may only take 15 minutes, but the patient may typically occupy the room for a longer period while he or she waits to be attended. Designating a longer time for this encounter than the time required for its tasks allows the true cost of the location facility to be accounted for, as described further below.
The details of encounters, tasks, and resources may be viewed in the detail window 14 by clicking on the desired item. A particular item may be selected so that its details are shown in the detail window either by clicking on the item in the library window 12 or by clicking on the item where it occurs in a pathway being shown in the pathway viewer window 16.
In Fig. 4, the detail window shows details of the Depression pathway 66, as described above. To see details about an encounter in a pathway, a user can click on the title of the encounter, and the detail window changes to show encounter information. For example, in Fig. 4, clicking on the encounter frame 88 will produce the detail window shown in Fig. 6. In Fig. 6, the window label 67 has changed to "Encounter," to indicate that details of an encounter are being shown. The name of the encounter is shown in box 68, and the sub-category of the encounter is shown at 70. Box 140 shows the location associated with the encounter.
Boxes 74 and 76 show the total cost and duration of the encounter. The cost of an encounter is calculated by adding three values. the sum of the costs of all resources used by tasks in the encounter; the total cost of any resources directly associated with the encounter; and the duration of the encounter multiplied by the hourly rate of the location where the encounter occurs.
Clicking on the name or frame of an individual task shown in the pathway viewer will show details of that task in the detail window 14. For example, clicking on the draw blood task 92 in Fig. 4 produces the detail window of Fig. 8. The label "Task, 11 the name of the task, and the task sub-category are shown at 67, 68, and 70 as before.
Resource window 80 shows the resources consumed by the task, and the cost and duration of the task are shown in boxes 74 and 76. The cost of a task is the total cost of all resources used by the task, and the duration is the longest duration required for reusable resources used in the task, which are values that are entered by a user when the task is defined, as discussed below.
The creation or modification of a pathway involves adding or modifying resources, tasks, encounters, and pathways. These items are all stored in the library database described in more detail below. The buttons 40 46 along the top of the library window 12 allow a user to select the type of item - pathways, encounters, tasks, or resources. Individual items may be selected or created using the library screen 12 as explained below. New items 16 may either be created from scratch or they may be made by copying an existing item and modifying it.
The procedures for creating a new resource, task, encounter, or pathway are similar. First, a user selects which type of item is to be created by selecting one of the buttons 40-48 along the top of the library window 12. The user then navigates along the tree structure until the desired subcategory is found. To create a new subcategory, a user would select the parent category and then click on the new category button 39 at the top of the library window, denoted by a plus sign in a shaded box, similarly to the shaded boxes of subcategories in the tree.
To create a new item, a user selects the desired parent sub-category and clicks the "create new item" button 37. The system then displays the appropriate screen described above in the detail display 14 window. The user must then type in a name f or the item. In the present invention, the system is designed so that the names of all pathways, encounters, tasks, and resources must be different. If a user tries to use a name already in the system, the system will add to the name to make it unique, for example by adding a numerical suffix. For example, if a user tries to name a task "admissions" when there is an existing "admissions" task, the system will change the name of the new task to "admissions-1.11 For pathways, the system will also ask for an optional code, such as a DRG code. This code is unique to the pathway. For an encounter, the user must enter a name and a location. For a task, only a name is required.
17 A new item may be created by copying an existing item and them modif ying it. Since one of the most useful features of the present invention is seeing the effects of modifications of existing procedures, copying an existing item is frequently done. to copy an item, the item is selected so that it appears in the detail window 14. This may be done by selecting the item in the library window or by selecting an encounter or task in a pathway displayed in the pathway viewer window 16. When the item to be copied is displayed in the detail window, the copy button 35 at the top of the detail window is clicked to make the copy. At this point, the system puts the cursor in the name box 68 of the detail window so that the user can enter a new, unique name for the copy. The newly named copy may then be modified as set forth below. If a new name is not entered by a user, a numerical suf f ix is added to make the name unique, as explained above.
The present invention also allows a user to locate a particular item by using a search function. To use this function, the user presses a designated key which brings up the search window 160 shown in Fig. 11. Initially, the results window 162 is blank, and the cursor is in a blank input box 164. After typing one or more words to be searched, the user presses enter and the system will search the library for all occurrences of the word or words item names. In Fig. 11, the results screen shows that the word "respiratory" occurs in the names of 17 encounters,, 22 pathways, 6 resources, and 27 tasks. The bullets to the lef t of each of the categories can be clicked to expand or collapse that category, as illustrated by the itemized 18 listing under resources. If the user clicks a particular item, the library window 12 will go to and display that item so that it may be selected by a user by clicking on it.
The lowest level object making up a pathway is a resource. All cost information is associated with the use of resources. Clicking the resource button 44 at the top of the library screen brings up the first level of resources shown in Fig. 10. It has been found that five categories of resources are generally sufficient to define all the resources used by a hospital. These categories are drugs, equipment, facilities, labor, and supplies, as shown in Fig. 10 by boxes 150-158. When a new resource is created, the screen of Fig. 12 is displayed. For each resource, a user must enter a unique name and a cost in boxes 166 and 168. Additionally, the user may check box 170 to indicate that the resource is reusable. When a resource is reusable, the cost data entered in box 168 is the cost per hour for the resource, and the cost for that resource is the cost per hour associated with the resource times the duration that resource is used. Normally, resources in the labor, equipment, and facilities categories are reusable, and drugs and supplies are not reusable.
Facilities are the locations where encounters take place, and the cost of a facility resource is the hourly cost of the location times the durationof the encounter.
Labor and equipment costs are determined by the amount of time that they are used. This time is entered by a user f or each of these types of resources as they are added to 19 a task, encounter, or pathway. For example, in Fig. 8, the durations for Laboratory Equipment and the Laboratory Technologist are different in the Draw Blood task shown since the equipment is required for the entire duration of the task, while the technologist is needed only for part of the time.
It is frequently useful to find a listing of all the activities in an activity or to see all the other activities in which a particular activity occurs. Fig. 13 shows a screen 184 which may be called up by a user to easily determine this information. To use window 184, a user would select an particular resource, task, encounter, or pathway in any of the library, detail, or pathway windows 12, 14, or 16. The user then presses a designated key to bring up the display shown in Fig. 13 in the detail window 14. The name 186 of the selected activity or resource is shown in the middle of the screen. Above the name of the selected activity 186 is an "IN" pane 180 listing all of the activities in which the selected activity occurs. For resources, window 180 will show all tasks, encounters, and pathways with which the resource is directly associated. Below the name 186 is a "HAS" pane 184 listing all the which are directly contained by the selected activity. In other words, if an encounter is selected, all super-tasks (tasks that have sub-tasks) in the encounter are listed in pane 182, but the tasks within those super-tasks are not. Being the top level of activities, pathways will have nothing listed in the IN pane 180, and likewise, resources will have nothing in the HAS pane 184. The display of Fig. 13 is easily generated using the data in the Steps Table shown in Fig. 20 and described below.
Bef ore describing how to modify tasks and encounters, the difference between global and local mode must be understood. After a task or encounter is def ined, it may be easily inserted into another procedure as described below so that the task or encounter does not have to be recreated each time it is used. Thus, a particular task or encounter may be used in many different pathways. If a user modifies a task or encounter, the user may want to modify that task or encounter in all the pathways where it occurs, or the user may only want to modify the task or encounter in a single selected pathway. In order to allow for these two possibilities, modifications to tasks and encounters selected from a pathway are made in one of two different modes, local mode and global mode. A user selects local or global mode by clicking on the mode button 34, shown in Figs. 1 and 4 to toggle between the two modes.
If a change to a task or encounter is made in global mode, then the change occurs in every pathway containing that task or encounter. When global mode is selected by the mode button 34, a task or encounter may either by clicking on an occurrence of that task or encounter in a pathway being displayed in the pathway viewer or by selecting the task or encounter in the library window.
When local mode is selected, a change made to a task or encounter will only affect the currently selected pathway shown in the pathway viewer window 16. All other occurrences of that task or encounter in other pathways will be unchanged. To accomplish this, when a change to a 21 task or encounter is made in local mode, the system makes a new copy of the original item and gives it a new name, such as by adding a numerical suffix to the original name. For example, if the Draw Blood task 92 in the Depression pathway 82 in Fig. 4 were modified in local mode, the system would create a new draw blood task named "Draw Blood-1. 11 This new task would be located in the library under the same sub-category as the original task. since a change to a task or encounter in local mode only affects a single pathway, when the user is in local mode, a task or encounter to be changed must be selected for the detail window by clicking on its name in the pathway view window 16. Selecting a task or encounter from the library window 12 in local mode will allow a user to view it in the detail window, but not to modify it.
In local mode, if an item that is changed is contained in or part of another item, then the local occurrence of that item is also copied and given a new name, the nonlocal occurrences of the item remaining as before. This procedure is continued up the hierarchy of super-tasks, and/or encounters unless and until a task or encounter is found that is not used elsewhere in another pathway In the present invention, tasks, encounters, and pathways are modified by using a "drag and drop" method to add and delete items. This is described below.
To modify a task, a user first selects global or local mode and then selects the task so that it appears in the detail window 14, as shown in Fig. 8, as described above. To change the duration of the task a user would right click the duration window 76 and enter a new duration. To add a 22 resource, the user would view the resource tree in the library window 12 and select the subcategory in which the resource is located, so that the resource is visible. Using the right mouse button, (because clicking with the left mouse button would replace the display of the task in the detail window with the resource details) the resource is then dragged and dropped onto the resources window 80 of the detail window. (It will be assumed that drag and drop operations described below are done with the right mouse button, even if not explicitly stated.) If the resource has a duration associated with it, i.e., if the resource is reusable, the default value is the duration of the task. Af ter a resource has been added to a task, the quantity and duration f ields may be changed. This is done by clicking on the resource and changing the quantity and duration values. A resource is removed by right clicking the resource name in the detail window, and then dragging and dropping it onto the trash can icon 24 at the side of the Pathway viewer window. 20 A task may be also modified by adding or deleting other tasks as a subtasks. This is described below. Modifying encounters is done in the following manner. Resources may be added directly to an encounter (as opposed to being added to a task in the encounter) similarly to the way in which resources are added to tasks. The encounter is first selected so that it is displayed in the detail window, such as those shown in Figs. 6 or 7. The desired resources are chosen from the library window and then dragged and dropped with the right mouse button to the encounter's detail window. To delete a resource directly 23 associated with an encounter, it is dragged and dropped from the encounter's detail window onto the trash icon 24. The def ault duration of an encounter is the sum of the longest set of sequential tasks that make up that encounter. A user may, however, enter a different duration by clicking on the duration box 76 and entering the desired duration. In the described embodiment, the system checks the newly entered duration and compares it with the default duration to ensure that a user cannot enter a duration less than the default value. It may be useful in some applications to disable this cross-check.
A task may be added to an encounter by right clicking the task in the library window and dragging it to the desired location in the displayed pathway. In the described embodiment, the icon denoting the dragging operation will change shape to indicate when the task is in a legal position in the pathway layout. Additionally, the new shape will change to indicate how the new task will be added. Thus, when the new task is inserted as a sequential task in an existing sequence, the icon will change to a right pointing arrow. To insert a task as a parallel task, it is dragged to the desired location and the icon changes to a down pointing arrow, at which point the task may be dropped. To insert a task as a subtask, the new task is dragged over the task to which it is to be added, the icon changes to a down or right pointing arrow, depending on its location, and the task is dropped. To remove a task, the task is right clicked in the pathway and dragged over to the trash can icon 24 at the side of the pathway viewer window.
24 Adding or deleting encounters to or f rom a pathway is done similarly. An encounter to be added to a pathway is right clicked in the library window and dragged to the desired location in the pathway viewer window. The icon will change to indicate to the user whether the encounter is to be added as a sequential or parallel encounter. Since a patient can only be in one location at a time, most pathways will not have parallel encounters. There are situations, however, where parallel encounters are required. For example, in an organ donation procedure, parallel encounters might be used to track procedures being performed concurrently on both the donor and the organ recipient. An encounter is deleted from a pathway by right clicking it and dragging it to the trash can icon 24.
Resources can be directly associated with a pathway by dragging and dropping them from the library window to the resources screen in the pathway's detail window, as described above for encounters.
While the above described methods of modifying the various items making up the pathways has been found to be intuitive and relatively easy to learn for non-technical people, it should be appreciated that other methods of modifying the pathways may be used without departing from the spirit of the invention. For example, a system could use the familiar cutting, copying, and pasting paradigm to edit pathways, encounters, and tasks.
The exemplary pathways used in the above explanation and shown in the accompanying figures are fairly simple. In actual practice, most of the pathways that a hospital will model will be much more complex. As discussed below, in general it is not necessary to accurately model all the pathways of a health care facility in order to get a reasonably accurate financial analysis, and typically the more important pathways are the more complex pathways that represent the more expensive procedures of a hospital.
Figs 9A through 9G show the full pathway f or a more complex procedure, in this case a respiratory system diagnosis with ventilator support procedure that lasts eight days. Figs.
9A-9G show a single, continuous pathway diagram that would normally be connected when viewed in the pathway window 16 but which must be shown in separate parts here due to the size of the pathway. Only the names of the pathway and encounters are shown in Figs. 9A-9G, but in the actual pathway, the names of all the activities would typically be shown (depending on the size of the display selected by a user). The names of the individual tasks super-tasks and sub-tasks need not be shown to illustrate the manner in which an extremely complicated hospital procedure can be easily modeled by the present invention. Fig. 9H shows the full detail of a part of this pathway.
Fig. 9A shows the beginning of the pathway, as indicated by the pathway Lframe 200. The first encounter is ER Arrival Ventilator Support 202. The encounter location is the hospital emergency room, and the encounter has a duration of 6 hours. This encounter includes an Intensive Ventilator Care task 204 which also lasts 6 hours and include sub-tasks 206. The encounter also includes a large number of individual tasks 208 that will be performed while the patient is in the emergency room, most of which are diagnostic tests.
26 Fig. 9B is a continuation of the pathway shown in Fig.
9A and shows the second encounter 210 in the pathway, Intensive Stay Ventilator Support-Days 1-4. The location associated with this encounter is an intensive care room, and the encounter duration is 4 days. Task 212 is the Intense Ventilator Support Day 1 task. It includes a series of test tasks 213 which make up super-task 214 named Lab Test Ventilator; a Ventilator Care super task 216 and various other individual tasks 218 that represent activities that take place during the first day, such as bathing the patient, medication, and other tasks.
The pathway 200 continues on in Fig. 9C, which shows the task 220 representing the second day of the patient's stay. it is similar to the first day, again including tasks 214 and 216 and various other tasks 222. The second day stay of task 220 additionally includes tasks for a pulmonary evaluation by a doctor 224 and a cardiac evaluation by a cardiac specialist 226. Following the Day 2 task in Fig. 9C is the Day 3 task 230, which continues on in Fig. 9D and which is similar to Days 1 and 2. The Day 4 task 232 is shown at the end of Fig. 9 A. Fig. 9E shows the Day 5 task 234. This task reflects that as the patient improves the Ventilator Care and Ventilator Lab Tests tasks 212 and 216 are no longer needed and not included among the tasks 236 that make up the Day 5 task 234.
The Day 5 task 234 marks the end of the Intensive Stay encounter 210. The next encounter 240 is Medical/Surgical Stay Days 1-2. This marks the transfer of the patient from the intensive care room associated with encounter 212 to a normal patient room associated with encounter 240.
27 Encounter 240 is shown in Figs 9E and 9F and includes two days of stay, designated by tasks 244 and 246.
Following the second day in the patient room, the patient is taken to the radiology room where x-rays are taken, as represented by encounter 252 in Fig. 9F. The patient is then returned to the patient room, as represented in Fig. 9G by the Day 3 patient room stay task in encounter 260, the last encounter in pathway 200. This encounter includes the various tasks 262 involved in patient support for the final day, and additionally includes a patient discharge task 264, including sub-tasks 266, such as patient education and out-patient medications.
One of the features of the present invention is presenting a pathway model such as that shown in Figs. 9A- 9G as a single diagram showing all the steps of patient care associated with a particular procedure. When presented in this fashion, it is easy for health care professionals to modify the pathways, as described above, to reflect the actual activities and costs of procedures as they are carried out by a individual hospital. In particular, it has been found extremely helpful to print out an entire pathway, such as that shown in Figs. 9A-9G, so that it may be reviewed and marked up f or revision and entry by the health care professionals actually involved in the proceeders, which may be a large number of people f or a pathway such as that just described. The input of these care providers on all levels f rom. surgeons to nurses to aids is important to providing an accurate model.
When large pathways are printed, it is preferable to print the pathway on a single sheet of connected computer 28 paper, sometimes caller "banner printing. For example, Fig. 9H shows the beginnings of the Day 2 Ventilator Support Intense task 220 from Fig. 9C in a legible size representative of the scale that would be used for review by health care staff. When printed in this scale, the entire pathway of Figs. 9A-9H will be twelve to fourteen f eet long. For this reason, printing the pathway in banner f orm as a continuous sheet is advantageous.
The data on which the pathway models described above are based is stored in a series of tables. The format of these tables is shown in Figs. 14 through 22. It should be appreciated that the format used in the tables described below is exemplary, and that after understanding the principals of the present invention, as explained herein, those of ordinary skill in the art may modify the particular format and arrangement of data storage described below without departing from the spirit of the invention.
To introduce some terms necessary to understanding the database structure, the library of pathway models described above is stored in a series of tables in which pathways, encounters, and tasks (including subtasks) are represented all as activities composed of one or more concurrent steps. Steps themselves are made up of encounters, or tasks. The difference between the concept of activities (pathways, encounters, or tasks) and steps is that activities are single defined procedures, while a step is a sequential ordered occurrence of a procedure which has a specific position relative to other steps. This operation is described in detail below.
29 Pathways, encounters, and tasks, each have their own separate table in which similar data is stored. The pathways table includes a series of records, each of which represents an individual pathway. Fig. 14 shows the fields 5 for each pathway record. The first field is the ID field. This is an arbitrary numerical ID used by the system as the key to the records stored in this table. Each of the tables storing data has its ID field, and in the present invention, the system ensures that the ID fields for pathways, encounters, tasks, resources, and classes (discussed below) are all unique, even across tables. The next f ield is the pathway name. This is the name of the pathway that is used to identify the pathway to the user on the computer display. Similarly to the ID fields, the is system ensures that the names of all pathways, encounters, tasks, resources, and classes are unique. This avoids confusion between, for example, an encounter and a task with the same name when a user is constructing or modifying a pathway as described above. The next f ield is the det ault duration of the pathway. This value is the sum of the sequential encounters that make up the pathway, or the longest set of sequential encounters if there are parallel encounters, as discussed above. The next f ield is the actual duration of the pathway and contains the duration of the pathway from the duration box 76 in the pathway description window shown in Fig. 4, either the default value or a longer value entered by a user.
The next field in the pathway table records is the code entered by a user from box 72 of Fig. 4. The next field is the total cost for the pathway. The total cost value is calculated whenever the pathway is created or modified by summing the cost of all included encounters plus the cost of any directly associated resources. Next is an optional description field that may contain 5 explanatory or other notes relating to the pathway. Finally, the described embodiment includes two fields to indicate the last time that the pathway was modified and a user ID to indicate who made the modification. These fields would be automatically determined by the system each time a pathway is modified.
Fig. 15 shows the format of the encounters table. The fields for each encounter record are similar to those in the pathways table. Thus, the fields include an ID field and an encounter name field that are unique. The default duration and duration fields respectively include the sum of the durations of the longest sequence of included tasks and the actual duration value entered by a user. The location field includes the ID of the facility resource where the encounter takes place. The total cost field is computed when the encounter is created or modified and is the sum of the costs of all included tasks plus any directly associated resources plus the duration of the encounter times the hourly cost of the location facility resource. The description, modification date, and modified by fields are as described above for pathways.
Fig. 16 shows the f ormat of the tasks table. The f ields, for each task record are similar to those in the pathways and encounters tables. Thus, the f ields, include an ID f ield, and a task name field that are unique. The default duration field depends on whether the task include
31 subtasks. If so, the default duration field is the duration of the longest sequence of included subtasks. If the task has no subtasks, the default duration field is the duration set by the user for the longest hourly resource that is included in the task. The duration field is the actual duration value from the duration box 76 of the task detail window shown in Fig. 8. The total cost f ield is computed when the task is created or modified and is the sum of the costs of all included subtasks, if any, and the cost of resources directly associated with the task. The description, modification date, and modified by fields are as described above for pathways and encounters.
The information used for displaying the tree structure of data shown in the library screen 12 is stored in a table of classes. Each record in the class table represents a box that is displayed in the library window 12 representing either a category or an pathway, encounter, task, or resource. Fig. 17 shows the fields for each item stored in the classes table. The first field is the numerical ID used by the system as the key to the records stored in this table. The next field is the class name. This is the name of either the category or the activity or resource that is displayed to the user in the library window hierarchal tree. The next field is the Parent Class. This field includes the ID of the category (i.e., the record in this Classes Table) of which this class is a branch. The next f ield is an Object Flag. This flag is set to indicate that the current record represents an object, such as a pathway, task, or resource rather than a category. In this case, the ID value in the classes table will match the activity 32 ID to match up an object in the library window with the corresponding activity. The next field is a System Flag. When set, this flag prevents a user from modifying the field. This flag is set, for example, for the top level box in each of the pathway, encounter, task, and resource trees. In the described embodiment, it is also set to protect the five top classes of resources. The next field is a pointer to an icon associated with the record. This icon is primarily used when the object represented by the record is dragged and dropped.
Fig. 18 shows the structure of the Resources Table. Each resource has a record in this table. The first field in this table is the ID key. The next three fields contain the data entered by a user in the resource detail window shown in Fig. 12 when the resource was created, including the resource name, the resource cost, and a f lag that indicates whether the resource is reusable.
Fig. 19 shows the f ormat of the resource uses table. Each time a resource is used in an activity, a new entry is made in the uses table which reflects that use. These records are reflected by the individual lines in a detail window resource screen showing the details of each resource use, such as those shown in Figs. 7 and 8. The uses table records include the uses ID f ield, and the ID for the resource that is being used. The uses ID is the same as the associated activity ID with which the resource use is associated. This is followed by a field f or the quantity of the resource being used and a f ield f or an optional duration.
33 The layout of each pathway model is determined by the data stored in three tables shown in Figs. 20, 21, and 22. These tables store data relating to steps in pathways. A step is an occurrence of an encounter or task somewhere in a pathway. The difference between the concept of encounters or tasks and steps is that encounters and tasks are single defined procedures, while a step is an occurrence of that procedure which may be present many different places in a collection of pathways. For example, the Draw Blood task 92 in Fig. 4 is a single activity, but this activity may be present as a step in many different pathways, encounters and other tasks; and thus the Draw Blood activity may make up many different steps.
Fig. 20 shows the format of data in the steps table.
Each individual step in every pathway will have an individual record in the steps table. The first field is the step ID field used to uniquely identify the step in the starting steps and next step tables discussed below. The second f ield in the steps table is the activity ID for the encounter or task that makes up that step. The third field is the inactivity field which identifies the activity in which this step occurs. For example, an activity that occurs 37 different times in the various pathways stored in the library will have 37 entries in the steps table. This list is used in coordinating changes to activities in global and local modes. If a change is made to a step in global mode, this list is used for ensuring that all activities which include this activity are updated. When a change is made to a step in local mode, a new activity with a new name is created unless the in-activity field is
34 empty, as described above. The steps table is also used to quickly generate the show structure display of Fig. 13.
The Starting step table shown in Fig. 21 contains data reflecting the starting step or steps of each activity that includes other activities. In other words, for each individual pathway, encounter, and task with subtasks, there will be a record in the starting steps table corresponding to each time it occurs in a pathway model. The first field is the activity ID which contains the activity ID for a particular pathway, encounter, or task. The next field is the starting step ID field which contains the step ID of the f irst step that is contained in the activity identified by the activity ID in the first field. For activities with multiple parallel procedures, there will be multiple entries in the starting step table. Each entry will have that activity's ID in the f irst f ield with the second f ield reflecting the first activity in each parallel line of procedures. Th third f ield in the start table indicates the ordering or relative graphical placement of the items, which is logically arbitrary in terms of the pathway model logic but may be important f rom, a user's perspective.
This is more easily explained by example. Referring to the pathway shown in Fig. 4, the ER Psychiatric-OP encounter has three parallel. lines of tasks. The first line includes the tasks in boxes 90, 96, 100, 104, and 110; the second line includes the tasks in boxes 92, 98, and 102; the third line includes the single activity in box 94. The starting steps table would include three records for this encounter. The first field of each of these records is the activity ID f or the ER Psychiatric-OP record in the encounters table. The second field for these three records will include the step ID I s of the records in the steps table for the for the three starting tasks, i.e., the "Admit Emergency" task 90, the "Draw Blood" task 92, and the "Continuing Case Management" task 94. The third f ield for these three records will be 1, 2, and 3, respectively, to ref lect the vertical arrangement of these three tasks shown in Fig. 4.
Similarly, for the Discharge Psychiatric outpatient task 110 in Fig. 4, the starting step table will contain two records, each with the ID for task 110 in the f irst f ield, the ID I s of subtasks 106 and 108 in the second f ields, and the position numbers in the third f ields.
The next step table shown in Fig. 22 reflects sequential steps that take place in an activity. Thus, each step that is followed by a succeeding step will have an entry in table 22. The first field is the step ID of the step and the second f ield is the step ID f or the following step. If the step is the last step in a sequence, the next step ID is a null value. For example, referring to Fig. 4, the Admit Emergency task 90 would have an entry in the next step table with its step ID as the first field, the second field having the step ID for the following MD ER Assessment task 96. This is repeated for the succeeding tasks 96, 100, 104, and 110 to define the sequential steps forming the top line in the ER Psychiatric-OP encounter 86. Task 110 will have a null next-step value, indicating that it is the last step in this sequence. Note that task 110 will, have two entries 36 in the starting step table, indicating that it has two subtasks. The data stored in the library database as described above is used to
provide the displays shown in Figs. 1-13. The display of information in the detail windows for pathways, encounters, and tasks is straightforward. The information is taken from the fields in the corresponding pathway, encounter, or task table and displayed in the appropriate place in the window. The library window is created from the data in the classes table.
The display of a selected pathway in the pathway window 16 is done in the following manner. Referring to Fig. 23, a user selects a pathway by clicking on it, block 302. The program then calls a "Display Activity" procedure block 304, that performs the actions necessary to construct and display the pathway from the data stored in the library.
The Display Activity procedure is shown in Fig. 24.
This procedure is a reentrant procedure that displays activities and also calls itself to display activities that are sub-parts of higher level activities. The activity ID is passed to the Display Activity procedure when it is called and based on this activity ID and the information stored in the step tables shown in Figs. 20-22 and the activity tables shown in Figs. 14-16, the program constructs the pathway diagrams. In this manner, pathways of arbitrary complexity may be stored and displayed using the data format and methods described herein.
The first step when the Display Activity procedure is called is to search the starting steps table in Fig. 21 to find starting steps, if any, for this activity, block 312. Any activity that includes one or more other activities will have a starting step entry. Thus, pathways, encounters, and super- tasks (tasks that include more or more sub tasks) will normally all have starting step table entries. The procedure when starting steps are found is described below, but first it will be helpful to follow the procedures when no starting steps are found for an activity.
When no starting steps are found, the Display Activity procedure goes to block 322. Normally this branch is taken only when the activity is a task, since tasks f orm the lowest level of pathways. It could happen, however, that this activity is an empty pathway or encounter in the process of being created.
In block 322, the next step table shown in Fig. 21 is searched to see if there is a following or next step. If a next step is f ound, the corresponding activity ID is determined from the steps table of Fig. 20, and the Display Activity procedure is called for this activity, block 326. If this next step itself has an included activity (i.e., has an entry in the starting step table) or has a following step, those steps will be processed as just described by another instance of the Display Activity procedure, and so on for succeeding steps, until no next step is found.
Returning to block 322, if there is no next step, the program goes to a do display routine in block 323. This occurs when the currently processed step is the last step 38 in a sequential series of steps. The do display routine constructs the graphical display of the current activity, based on the current activity ID and the data in the activities tables of Figs. 14-16. Normally the display created in box 323 will be a box with the task name. As discussed above, it is possible that displayed activity is a pathway or encounter under construction, in which case a frame display will be created. After the activity display is constructed for the currently processed step, the Display Activity procedure will return to the call display activity block, that called the current instance of the call display procedure block 324.
Thus, as will become more clear below, after all the steps in a series of sequential steps have been processed, the nested sequence of Display Activity procedures will all return until the current instance of block 326 is reached.
After each return, the Display Activity procedure will perform the do display procedure in block 327 for the current activity and then return to the previous procedure, block 328, so that the display of each sequential steps is actually created from the end of the sequence backwards.
Returning to block 312, if one or more starting steps are found in the starting step table, the first starting step is determined, block 330. This step would be the first step in the first row of one or more sets of parallel activities, as described above. The activity ID for that step is determined from the steps table, and the Display Activity procedure is then called for the activity, block 332. After the program returns to block 332, the program checks to see if there is another starting step, block 334, 39 if so, the program goes back to block 332 to display the next series of sequential steps.
When no more starting steps remain to be processed, the procedure goes to the do display routine in block 335.
At this point in the processing of the pathway, all of the sets of parallel steps that make up the currently-processed activity have been processed and the associated display boxes or L-frames have been created. The do display routine in box 335 will create the L-frame and title for the current activity and add it to the pathway display. The procedure next returns to the calling instance of the Display Activity procedure, block 336.
When all the steps in a pathway have been processed, as described above, the program (i.e., the first called instance of the Display Activity procedure) returns to block 304 in Fig. 23, and then pathway display program ends, block 306.
The operation of the procedures shown in Fig. 24 may be better understood by applying it to an actual pathway example, such as the depression pathway shown in Fig. 4.
To create this pathway, the program would first determine the pathway ID when it is selected by the user f rom the library screen 12 and call the Display Activity procedure, block 304. It next looks in the starting step table and finds a single step ID for encounter 86, block 312.
Referring to the steps table, it identifies the ER Psychiatric-OP encounter 86 as the starting step and calls the Display Activity procedure with the ID for this encounter, block 332.
This second instance of the Display Activity procedure determines that encounter 86 has three starting steps, block 312. Using the steps table, it determines that the admit emergency task 90 is the activity associated with the f irst step, block 330, and the Display Activity procedure is called to display this activity, block 332.
This time, no starting steps are f ound f or the retrieved activity (task 90), block 312, so the program next looks to see if there is a next step f ollowing task 90. The step ID for the next sequential step, which is task 96, is found in block 322, and again the Display Activity procedure is called to display this activity, block 326.
This sequence is repeated to process the sequential tasks 100, 104 and 110.
When the step corresponding to task 110 is processed, the Display Activity procedure takes the branch to block 330, where subtasks 106 and 104 are found, and the Display Activity procedure is called for task 106. When task 106 is processed by the Display Activity procedure called in block 332, the locate next step block 322 finds no next step, the box and label for task 106 are generated, block 323 and the current instance of the Display Activity procedure returns, block 334. Note that this is the first time that a Display Activity procedure has returned and the first time that a part of the pathway display has actually been generated during the processing so far of the entire Depression pathway 82. Next, task 108 is processed and the display created via blocks 312 322 and 323, similarly to task 106.
41 There is then a series of returns from the nested Display Activity procedure described above until ultimately the Display Activity procedure that processed the first task 90 returns to block 332, after which the next starting step for encounter 86 is processed. The displays for the various tasks are generated and added to the pathway display by blocks 327 and 335 prior to each of these returns. The above procedure is repeated to create the displays of the two additional parallel task sequences consisting of tasks 92, 98, and 102 and of single task 94.
Finally, the first called display activity procedure is reached by a return to block 332, no further starting steps are found for pathway 86, block 334, the pathway L-frame display is created, block 335, and the Display Activity procedure returns to block 304 in Fig. 23.
once the above procedures have been carried out to model the pathways for the various procedures of a hospital, it is straightforward to use this information in further financial reports and analyses. Most information required for such further processing is contained in a single table, the pathways table shown in Fig. 14. This table provides the actual cost to the hospital, the total duration of the patient stay, and the DRG code. These are the three most prevalent indices used in computing insurance reimbursements that are based on other than per capita payments. By entering data which represents the number of each of the procedures performed by the hospital, as represented by the various patient pathways, the total direct costs to the hospital may be computed and displayed in various forms. By entering patient pathway data for 42 alternate procedures, which may be done at the pathway, encounter, or task level, or at all three, so-called "whatif" analyses may be easily performed to determine the effect of direct costs of changes in procedures. Cost accounting techniques for carrying out these analyses are well known in the art, and once the data stored for pathways has been accumulated by the present invention, analyzing this data can be easily performed by one of ordinary skill.
It has been found that by using the present invention for modeling patient pathways, reasonably accurate financial data and analyses can be generated without having to model all of the pathways performed by a hospital. Typically a hospital may perf orm procedures that would require two to three hundred patient pathways f or one hundred percent modeling of all the hospital Is patient activities. Of these several hundred pathways, twenty to thirty pathways will typically make up 65 to 80 percent of the actual direct costs f or patient treatment. By using the data generated by the pathway modeler of the present invention in conjunction with readily available tables relating the costs and/or complexity of the various procedures, reasonably accurate estimates of non-modeled pathways may be made which will allow a complete financial analysis to be performed, even in the absence of pathway models for all patient procedures. The method by which this is done is described below with reference to Figs. 2527 Referring to Fig. 25, a table or matrix is constructed 30 with data for each of the modeled pathways. In this 43 matrix, each pathway has its own line 402-405, representing the first modeled pathway through the last modeled pathway, designated N. Using pathway cost data generated by the pathway modeler described above, the total cost for the resources for each modeled pathway in each of the five resource categories described above drugs, equipment, facilities, labor, and supplies - is entered into the appropriate column 411-415 for that pathway. The next column 420 contains a value that represents the relative complexity or cost of the pathways with respect to one another. This value will be used in computing a scaling factor used to estimate costs of non-modeled pathways, as described below. In the described embodiment the values entered in column 420 are the values for the DRG corresponding to the pathway taken from the Medicare Table of Relative Acuities as compiled by the Health Care Financial Association (HCFA). Finally, patient volume data, taken from the hospital care records for the desired time period are entered in column 422. Although the HCFA values used in the described embodiment have been found to provide good results in calculating cost for unmodeled pathways, it should be appreciated that other industry recognized indices of the relative complexities of the modeled procedures may be alternatively used with the described procedure in place of the HCFA values.
After the above-described data is entered for each of the modeled pathways, the sum of the costs f or each of these categories is computed, as shown in line 408. Thus, a value ED is computed which is the sum of the drug cost figures D1, D2, through Dn for each of the individual 44 procedures that have been modeled as pathways. The same is done to compute corresponding values ZEI ZFI EL, and Es for the equipment, facilities, labor, and supplies resource groups respectively, as shown in row 408 for columns 412 415. Also, the sum of the individual HCFA values for each pathway is computed. Thus Emli is the sum of the HCFA values for all of the modeled pathways Hmj, Hm2, through Hm.
Next, a second table is computed to determine the cost data for unmodeled pathways, as shown in Fig. 26.
Similarly to the table shown in Fig. 25, each unmodeled pathway representing a procedure performed by the hospital will have a separate row 431-434. The columns in Fig. 26 are the same as for Fig. 25. Columns 411-415 represent the resource category cost for each pathway computed as set forth below. Columns 420 and 422 contain the HCFA value for the procedure of the pathway 420, and patient volume data from hospital care records 422.
First, a scaling factor K is computed using the following equation:
K = (ED + ZE + EF + EL I ES) /EMH (1) ------In- ot, r words, -K--is-equ to th sum of t' resour-ae costs for all of the modeled pathways, divided by the sum of the HCFA values for these pathways. For each of these unmodeled pathways, the estimated 25 cost is for the pathway calculated for each of the five resource group categories by multiplying the scaling value K above by the HCFA value f or the pathway whose cost is being estimated. To break down the cost of a pathway into the resource, the total cost is multiplied by a f actor 30 equal to the total cost of that resource from the modeled pathways to the sum of all resource costs from the modeled pathways.
For example, to compute the drug resource cost for the first unmodeled pathway, Dul, the following equation would 5 be used:
Dul 2-- K x Hul X ED/ (ED + EE + EF + EL + Es) (2) where Hul is the HCFA value for the pathway. Plugging equation (1) into equation (2) gives:
D., = HUIXED/EMH(3) where EmH is the sum of all HCFA values f or the modeled pathways, as shown in Fig. 25. This procedure is carried out to calculate the costs f or each category of resources for each of the unmodeled pathways, as shown by the equations in Fig. 26.
In Fig. 27, a table is shown that may be used with the present invention to quickly analyze general ledger f igures for a hospital to provide an indication of where problems may exist. In Fig. 27, there are hospital operation figures for each of the five categories of resources, as shown in columns 441-445. Each resource category has four -----va-l-u s shovn-...-d r-t --asts, indirect Osts, V a total costs, as shown in lines 451-453.
The direct costs line 451 represents the direct costs to the hospital for each of the resource categories used in patient procedures, as calculated using modeled patient pathways, along with the method set forth above to account for any unmodeled pathways. The values in this line 451 are calculated by multiplying the resource category cost for each pathway by the patient volume for that pathway from columns 422 in Figs 25 and 26.
46 The total cost f igures for each of the resource categories shown in line 453 are taken from the general ledger figures of the hospital. The indirect costs in line 454 for each of the resource groups are likewise determined from the general ledger and a resource allocation table to reflect overhead, as determined by the hospital accounting system. The variance line 452 is the difference between the direct costs in line 451 and the total resource costs shown in line 453. As the number of pathways modeled increases, the changes in the variance line will become smaller, and this can be used as an indicator of when a sufficient number of pathways have been modeled to ensure reasonable accuracy.
Additionally, the variance line itself has been found very helpful in identifying potential problem areas in hospital finances. For example, excess variance in supplies and drugs can indicate wastage, and labor variances greater than 1.0 to 1.5 times the direct costs indicate staff inefficiencies.
There has been described a new and useful method and app ratus for diiatTzAiTnyg--aTnRdt---disp-l-ayiny j spital and health care costs. While the operation and advantages of the invention have been described with reference to the exemplary embodiments described above, it should be appreciated that modifications to these embodiments will be made by those of ordinary skill in the art in applying the teachings of the invention to different situations and applications. Accordingly, the present invention should not be limited by the embodiments described above, but 47 rather the scope of the invention should be interpreted in accordance with the following claims.

Claims (23)

  1. 48 CLAIMS
    I A method of modeling a plurality of patient care procedures performed on a patient in a health care facility to provide models representative of the modeled procedures, the method comprising the following steps:
    storing a plurality of resource data sets, each data set being representative of a resource item which is used in patient procedures and which has a cost value associated therewith, each data set including data representative of the resource item name and a cost value associated with the resource item; storing as part of the resource data sets a plurality of facility resource data sets for resource items that are associated with physical locations in the health care facility and which include cost data representative of the hourly cost of the associated physical location; storing a plurality of task data sets, each task data set representing a task performed during the care of a patient, each task data set including data representative a-, -L-R time-d-urat-iorr-of the task, dnid-th-07resource items which are required to carry out the task; storing a plurality of encounter data sets representative of associated tasks performed for a patient at an associated single location in the health care facility during a patient care procedure, each encounter data set including data representative of: an encounter name, a facility resource data set associated with said single location, a duration value representative of the time that a patient remains in said single location, and 49 all tasks performed for a patient at the associated location; storing a plurality of pathway data sets, each pathway data set representing an associated patient care procedure, each pathway data set including data representative of the names of the one or more encounters that are performed during the associated patient care procedure; providing a means for a user to select a particular pathway data set; and providing a graphic display of a model of the selected pathway on the screen of a display device, including the steps of: displaying a first series of symbols representing the encounters included in the pathway, each symbol representing one encounter in the selected pathway; and displaying for each encounter a second series of symbols graphically associated with said each encounter, the symbol being representative of the tasks included in that encounter.
  2. 2. The method of claim 1 further including the steps of: for each task in the selected pathway, determining a calculated total task cost including the step of summing the costs of all associated resources for the task; providing a means for selecting a particular task; and displaying the calculated total task cost of the selected task.
  3. 3. The method of claim 1 further including the steps of:
    f or each encounter in the selected pathway, determining a calculated total encounter cost including the step of summing the costs of all tasks performed during the encounter; 5 providing a means for selecting a particular encounter; and displaying the calculated total calculated encounter cost of the selected encounter.
  4. 4. The method of claim 3 wherein the step of determining a calculated total encounter cost further includes the step of multiplying the hourly cost of the associated location by the duration of the encounter.
  5. 5. The method of claim 4 further including the steps of determining a calculated total pathway cost including the step of summing the costs of all encounters included in the pathway; and isplaying the total calculated pathway cost.
  6. 6. The method of claim 5 wherein: the task data sets further include data representative of the duration of the task; and the step of storing resource data sets includes the step of storing data representative of whether the resource is reusable having a cost value dependent on time or nonreusable having a fixed cost value, the stored cost value of a reusable resource item representing the hourly cost of the resource.
    51
  7. 7. The method of claim 6 wherein the step of determining the total calculated task cost further includes the step of determining the total calculated task cost by summing the costs of each associated resource item that is non-reusable and adding thereto the cost of each reusable resource item multiplied by the duration of the task; and
  8. 8. The method of claim 7 wherein; the task data sets include optional data representative of total task cost, and further including the step determining an actual total task cost by comparing the calculated total task cost with the data representative of total task cost and selecting the larger value.
  9. 9. The method of claim 8 wherein: the encounter data sets include optional data representative of total encounter cost; and further including the step of calculating an actual total encounter cost by comparing the calculated total encounter cost with the data representative of total encounter cost and selecting the larger value.
  10. 10. The method of claim 9 wherein: 25 the pathway data sets include optional data representative of total pathway cost; and further including the step of calculating an actual total pathway cost by comparing the calculated total pathway cost with the data representative of total pathway cost and selecting the larger value.
    52
  11. 11. The method of claim 10 wherein the encounter data sets include each include optional data representative of resources which are directly associated with the encounter but not part of a task performed at the associated location; wherein the pathway data sets include optional data representative of resources which are directly associated with the pathway; wherein the step of determining a calculated total pathway cost includes adding in the cost ofresources directly associated with the pathway; and wherein the step of determining a calculated total encounter cost includes adding in the cost of resources directly associated with the encounter.
  12. 12. The method of claim I wherein the step of storing a plurality of task data sets includes the step of storing data representative of other task data sets, to represent super-tasks which include other tasks and the resource associated therewith. thereby allowing the resources required to carry out a task to be included in other tasks that use additional resources.
  13. 13. The method of claim 12 wherein the step of storing a plurality of encounter data sets includes the step of storing data representative of a sequential series of tasks which are performed in a predetermined sequential order.
    53
  14. 14. The method of claim 13 wherein the step of storing a plurality of encounter data sets includes the step of storing data representative of simultaneously-occurringtasks, including both (1) single tasks and (2) sequential series of tasks, which data represents tasks and sequential series are carried out at the same time.
  15. 15. The method of claim 14 further including the steps of: storing first sets of data in a starting step table, each first data set including data representative of (1) the name of an encounter, and (2) the f irst tasks of a sequential series of tasks performed in the named encounter for each sequential series of tasks which is part of the named encounter, and storing second data sets in a next step table, each second data set including data representative of (1) a step ID identifying a task in an encounter, and (2) a next step ID identifying the task, in a sequential series of tasks, following the task identified by the step ID in the second data set.
  16. 16. The method of claim 15 further including the steps of: storing third sets of data in the starting step table, each third data set including data representative of (1) the name of a task which includes other tasks and (2) the first tasks of a sequential set of tasks performed in the named task for each sequential series of tasks which is part of the named task; and storing fourth data sets in the next step table, each second data set including data representative of (1) a step 54 ID identifying each task which is part of another task; and (2) a next step ID identifying the next task following the task identified by the step ID in that data set.
  17. 17. The method of claim 14 wherein the step of providing a display of the selected pathway includes:
    displaying a graphical symbol associated with the selected pathway and which defines a f irst area of the screen; displaying a plurality of second graphical symbols representing each of the encounters associated with the selected pathway, each of said second graphical symbols being displayed within the f irst area of the screen, and each of the second graphical symbols defining a second area of the screen associated with encounter represented thereby; and displaying a plurality third graphical symbols representative of the tasks associated with each of the encounters in the selected pathway, each of the third graphical symbols representing a task performed during a respective one of the encounters associated the selected pathway, and each of the third graphical symbols being display within the third area of said respective encounter.
  18. 18. The method of claim 17 further including the steps of:
    displaying each sequential series of tasks included in an encounter with the individual tasks arranged in sequential order in a first direction to represent the sequential series of tasks; and displaying simultaneously-occurring-tasks in an encounter arranged in a second direction different from the first direction.
  19. 19. The method of claim 18 wherein the first direction is horizontal across the screen and the second direction is vertically up and down the screen.
  20. 20. The method of claim 19 further including the steps of: 10 displaying the third graphical symbols so as to define third areas associated therewith on the screen; and wherein a super-tasks has its included tasks displayed by symbols located with its third area on the screen.
  21. 21. The method of claim 20 further including the steps of:
    displaying each sequential series of tasks included in a super-task with the individual tasks arranged in sequential order in said first direction to represent the sequential series of tasks; and displaying simultaneous ly-occurring-tasks in a super task arranged in said second direction.
  22. 22. The method of claim 17 further including the steps of:
    displaying a collection of library symbols, each symbol representing a resource item, a task, a super-task, or an encounter represented by data in the resource, task, and encounter data sets; providing a pointing device by which a particular library symbol may be selected; 56 enabling the pointing device to move a selected library symbol into a selected position in the graphical display of the selected pathway and to insert it there forming a modified model of a patient care procedure; and after a library symbol has been inserted, modifying the data sets to reflect the structure of the modified model.
  23. 23. The method of claim 22 further including the steps of: providing a pointing device by which a symbol in the pathway display representing an encounter, super-task, or task may be selected; enabling the pointing device to move the selected pathway display symbol to a defined disposal area on the screen to release it there forming a modified model of a patient care procedure from which the encounter, super task, or task has been removed; and after a pathway display symbol has been removed, modifying the data sets to reflect the structure of the modified model.
GB0013811A 1999-06-09 2000-06-06 Computer modelling of health care procedures Withdrawn GB2354853A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US32917399A 1999-06-09 1999-06-09

Publications (2)

Publication Number Publication Date
GB0013811D0 GB0013811D0 (en) 2000-07-26
GB2354853A true GB2354853A (en) 2001-04-04

Family

ID=23284197

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0013811A Withdrawn GB2354853A (en) 1999-06-09 2000-06-06 Computer modelling of health care procedures

Country Status (1)

Country Link
GB (1) GB2354853A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2847056A1 (en) * 2002-11-08 2004-05-14 Surgiview Processing of evaluation data, e.g. for use by a doctor in evaluation of the treatment of a patient, or on a larger scale, evaluation of the development of a company based on an initial state and decisions and actions taken
US11257593B2 (en) 2014-01-29 2022-02-22 Umethod Health, Inc. Interactive and analytical system that provides a dynamic tool for therapies to prevent and cure dementia-related diseases

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113421639B (en) * 2021-04-27 2023-11-10 望海康信(北京)科技股份公司 Clinical path forming system, method, corresponding equipment and storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995024114A2 (en) * 1994-03-07 1995-09-14 Scovell, Peter, George Improvements in project management computer programs
WO1997040463A1 (en) * 1996-04-23 1997-10-30 Deroyal Industries, Inc. Method for the administration of health care employing a computer generated model
GB2324942A (en) * 1997-05-02 1998-11-04 Ibm Hierarchical node structure
WO1999024927A1 (en) * 1997-11-07 1999-05-20 Deroyal Business System, L.L.C. Modular health-care information management system utilizing reusable software objects

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995024114A2 (en) * 1994-03-07 1995-09-14 Scovell, Peter, George Improvements in project management computer programs
WO1997040463A1 (en) * 1996-04-23 1997-10-30 Deroyal Industries, Inc. Method for the administration of health care employing a computer generated model
GB2324942A (en) * 1997-05-02 1998-11-04 Ibm Hierarchical node structure
WO1999024927A1 (en) * 1997-11-07 1999-05-20 Deroyal Business System, L.L.C. Modular health-care information management system utilizing reusable software objects

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2847056A1 (en) * 2002-11-08 2004-05-14 Surgiview Processing of evaluation data, e.g. for use by a doctor in evaluation of the treatment of a patient, or on a larger scale, evaluation of the development of a company based on an initial state and decisions and actions taken
WO2004044813A1 (en) * 2002-11-08 2004-05-27 Surgiview Method and system for processing evaluation data
US11257593B2 (en) 2014-01-29 2022-02-22 Umethod Health, Inc. Interactive and analytical system that provides a dynamic tool for therapies to prevent and cure dementia-related diseases
US12046369B2 (en) 2014-01-29 2024-07-23 Umethod Health, Inc. Interactive and analytical system that provides a dynamic tool for therapies to prevent and cure dementia-related diseases

Also Published As

Publication number Publication date
GB0013811D0 (en) 2000-07-26

Similar Documents

Publication Publication Date Title
Radnor Implementing lean in health care: making the link between the approach, readiness and sustainability
Wang et al. Modelling and simulation of emergency services with ARIS and Arena. Case study: the emergency department of Saint Joseph and Saint Luc Hospital
Plaisant et al. LifeLines: visualizing personal histories
US5592945A (en) Real-time event charting in an electronic flowsheet
US20030050801A1 (en) System and user interface for planning and monitoring patient related treatment activities
US20030036925A1 (en) Order generation system and user interface suitable for the healthcare field
US20030220815A1 (en) System and method of automatically determining and displaying tasks to healthcare providers in a care-giving setting
US20130006649A1 (en) System and Method Healthcare Diagnostics and Treatment
WO1997006498A1 (en) Spreadsheets and charts system specialized for medical use
US7254782B1 (en) Recordation and organization of problem solving data
US20130346106A1 (en) Integrated Health Data Navigator Based On A Single Timeline
Gulliksen et al. Domain‐specific design of user interfaces
Ghazi et al. Challenges of working with artifacts in requirements engineering and software engineering
US8856150B2 (en) Managing and displaying solutions for multiple resources in an appointment scheduling system
Victor et al. Dashboard visualisation for healthcare performance management: Balanced scorecard metrics
CA2698937C (en) Software system for aiding medical practitioners and their patients
US20210390086A1 (en) Method and system for lexical data processing
US20040078240A1 (en) Method and apparatus for capturing and analyzing individual patient clinical data
GB2354853A (en) Computer modelling of health care procedures
Seila et al. Opportunities and challenges in health care simulation
Nenonen et al. A theoretical framework for health information systems
Faerber et al. A comprehensive modeling language for clinical processes
Stead et al. Demand-oriented medical records: toward a physician work station
Moraes et al. Value stream mapping: an application lean in the process of accountability in a philanthropic hospital
Chambers et al. Improving Processes for Health Care Delivery

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)