WO2006000041A1

WO2006000041A1 - A hospital modelling system

Info

Publication number: WO2006000041A1
Application number: PCT/AU2005/000926
Authority: WO
Inventors: Donald Alexander Campbell; Christopher Ashley Bain; Philip Raymond Cooper
Original assignee: Monash University
Priority date: 2004-06-24
Filing date: 2005-06-24
Publication date: 2006-01-05

Abstract

A hospital modelling system including (i) a configuration module including patient data representing patients, bed cluster data representing a bed cluster of beds corresponding to a treatment type, and treatment plan data representing treatment plans including treatment types, and (ii) a simulator for processing the patient data and allocating patients to treatment plans, and allocating patients to beds based on a treatment type of the allocated treatment plan.

Description

A HOSPITAL MODELLING SYSTEM

FIELD

The present invention relates to a hospital modelling system, and in particular to a method for representing or simulating the movement of patients in a hospital.

BACKGROUND

Administering hospitals and allocating staff, doctors and patients to the facilities available in a hospital is an extremely difficult and complex task, particularly with the increasing development of a wide variety of medical procedures and surgical techniques. The resources a hospital has at its disposal are finite and, due to funding constraints, demand can commonly exceed supply.

Simulation modelling is particularly useful for addressing the problems which beset decision making in health care delivery. There is a critical need for tools to help clinicians, administrators and policy makers to make good decisions. Health care managers traditionally rely on deterministic analytical techniques for decision making. Many clinicians doubt the capability of simulation models to capture the complexity and unpredictable nature of health care. Yet these characteristics lend themselves to simulation modelling.

Computer based systems have been developed to assist hospital managers with the allocation of patients to the resources, and vice versa. The system may be sophisticated enough to be able to produce a simulated model of the hospital and indicate to a manager changes to attributes of the hospital resources that should be made in the actual hospital. The inherent difficulties associated with the existing systems are: (i) The systems inherit and are constrained by the actual physical structure of the hospital. For example, the systems import constraints concerning the wards that need to be used for certain treatments and reinforce how different wards are allocated to specific treatment units within the hospital, (ii) Patients on arrival and during treatment are allocated to wards or clinical units of the hospital, again based on physical constraints and layout of the hospital. The patient allocation is restrictive, and to some extent cumbersome to perform when attempting to simulate operation of the hospital. (iii) Patient movement through a hospital does not take into account the interaction between the individual patient characteristics, their treatment plan, and the availability of resources within the hospital.

It is desired to address the above, or at least provide a useful alternative.

SUMMARY

In accordance with the present invention there is provided a method executed by a hospital modelling system, including: processing patient data representing a patient and allocating the patient to a treatment plan; and allocating the patient to a bed based on a treatment type of the treatment plan, said bed being from a bed cluster corresponding to said treatment type.

The present invention also provides a hospital modelling system, including: a configuration module including patient data representing at least one patient, bed cluster data representing a bed cluster of one or more beds corresponding to a treatment type, and treatment plan data representing at least one treatment plan including at least one treatment type; and a simulator for processing said patient data and allocating a patient to one of said at least one treatment plan, and allocating the patient to a bed based on a treatment type of the allocated treatment plan. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a hospital modelling system connected to a hospital administration system; Figure 2 is a block diagram of a simulator of the hospital modelling system; Figure 3 is a flow diagram of a simulation process performed by the hospital modelling system; Figure 4 is a display of part of a plan sheet of the system; Figure 5 is a display of part of a treatments sheet of the system; Figure 6 is a display of part of an arrivals sheet of the system; Figure 7 is a display of part of a sessions sheet of the system; and Figure 8 is a screen shot of a graphics display produced by the system.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

A hospital modelling system 100, as shown in Figure 1, includes a simulator module 102 and a configuration module 104. The system 100 is able to simulate or represent patient flow or movement within one or more hospitals using data extracted from a standard hospital administration system 108. The data includes information on patients, dates of admission, treatments performed, beds allocated to wards, surgical theatres, etc, that would normally be maintained in the administration of a hospital. The patient and hospital data can be manually entered into the configuration module 104 or extracted automatically using an extraction module 106 that may be provided with the system 100.

The simulator 102 processes the data of the configuration module 104 to first establish a run time database 216 providing a specification that defines the requirements of a simulation run. The specification includes patient arrival streams and the rules used to allocate attributes to patients, such as a treatment plan a patient is to undertake in a hospital. The simulator 102 manages events that would occur within the hospital and allocates patients to beds based on the treatment type specified at any given point in time, when a simulation is run after initialisation.

The hospital system 100 allocates beds to clusters, where each cluster relates to a specific treatment type, eg burns recovery, instead of allocating beds to a ward. A cluster may include one or more beds. A ward may comprise one or more bed clusters each cluster being within a single ward. A specific treatment type may relate to one or more clusters. The allocation of clusters of similar treatment type between wards allows and determines the geographic dispersement of treatment. An alternative is that a cluster may comprise one or a number of wards, and may also be geographically dispersed.

The attributes assigned to' patients on admission via the patient streams is done stochastically using different entry points to a deterministic tree structure, as discussed below.

The logic provided and executed by the simulator 102 remains the same for each simulation performed by the system 100, and accordingly the simulation is controlled by the configuration module 104. This provides considerable flexibility, as various hospitals and scenarios can be simulated with the logic of the simulator 102, using different configurations defined by the configuration module 104.

The simulator 102, as shown in Figure 2, includes a number of modules 202 to 214 that are able to communicate with one another over a bus 220 of the system 100. A command interpreter 206 initially processes the data held in the configuration module 104 to build the initial run time simulation database 216, maintained on a database server 214 of the system 100. The interpreter 206 controls the overall logic flow and includes subordinate interpreters dedicated to scripts on various sheets of the configuration module 104. The interpreter 206 triggers a number of parallel threads of activity defined by the configuration module 104. The threads include one or more continuous patient arrival streams, cyclic scheduled events such as surgical sessions and calendar synchronised events such as public holidays. Each thread results in a sequence of primary and consequential events that determine the sequence of activity in the simulated hospital.

A thread is an independent sequence of events. In some cases the entire sequence can be scheduled in advance, eg the start and end of a shift. In other cases the circumstances prevailing at the time of an event will determine the subsequent action and the nature and timing of the next event for the thread, eg patient progress to the next stage of treatment depends on the availability of a suitable bed at the time when the patient is ready.

Each of the following is controlled by a separate thread: (a) Each patient arrival stream (b) Each patient from arrival to discharge (c) Each theatre session following its cyclic scheduling (d) A cyclic theatre session scheduler (e) As many calendar synchronised threads as required for such things as (i) Public holidays (ii) Once only configuration changes (iii) Episodic demand fluctuations (f) As many cyclic threads as are required for such things as: (i) Daily shift patterns (ii) Weekly activity cycles (iii) Seasonal activity changes

The event management module 202 manages all future events to ensure that the activities of all the parallel threads are correctly interleaved and are processed in the correct sequence and at the correct time with reference to the system clock. When an event is triggered, the interpreter 206 takes the next action required by the relevant thread and schedules a further event if required. Some threads use scripts to resolve the complex decisions associated with deciding the next action and scheduling the next event. Such an action may be to allocate a patient to a specific treatment type as specified in the patient's treatment plan. Scripts are specified in the configuration module 104 and are transferred to the simulation database 216 during the initialisation of the simulation run.

A dynamic memory allocation module 204 establishes and maintains a set of queues 210 used by the event management module 202 and to track waiting entities whose progress is impeded by other events. The purpose of an individual queue determines whether it is managed using LIFO₅ FIFO or priority principles.

The simulator 102 also includes a graphics display module 208 which is able to drive a visual display 218 to provide a graphic representation of the current state of the hospital system 100, based on state variables of the simulation maintained on the database server 214.

The system 100 logically separates patient streams, the structure of a hospital and the medical procedures that need to be performed thereby allowing them to be adjusted independently as desired.

The configuration module 104 includes declarative and procedural components. The declarative components are sheets of data that define patient arrivals, attributes, bed clusters, theatre session schedules, surgeons, etc. The procedural components include three different levels of procedural scripting, and the scripts can be considered to provide an extension of the logic of the simulator 102. Each script is served by its own interpreter of the command interpreter 206. At the completion of any script step, control passes to the appropriate interpreter to invoke the next step. The three levels are:

1. A treatment plan, being a row on a plan sheet of the configuration module 104, defines steps of a treatment path that can be allocated to a patient. The treatment plan controls the steps or the sequence of treatments that the patient will receive. The steps each define a treatment type that will be applied to the patient at a given point in time during their admission. The length of the steps is variable. Associated with each step is a distribution of treatment times. For each patient upon - 1 -

progression to the next step of the allocated plan the distribution is sampled to determine the absolute length of the treatment the patient will receive at this step. The treatment plan is allocated on arrival by the attribute assignment process and the progress of the patient through the plan is governed by the event management module 202 and the simulation state variables that it monitors. The following state variables are used to track the progress of an individual patient through the hospital: (i) the allocated plan, (ii) the current plan step, (iii) the current treatment type, (iv) the treatment therapy step, (v) the occupied cluster, (vi) the admitting unit, and (vii) a record of any outstanding requests or events pending for the patient. A plans sheet of the configuration module 104 defines all of the treatment plans for the hospital. A distribution sheet is included in the configuration module 104 and is used to specify statistical distributions for use in various parts of the simulation. The distribution sheet permits the specification of regular distributions that are capable of specification using parametrically driven functions or empirical distributions that follow no mathematical rules. The distribution sheet may be used as an extension of the plan sheet in order to specify the treatment time distribution associated with a particular plan step. Figure 4 shows an extract from a plans sheet showing the first four plan steps.

A treatment sheet of the configuration module 104 defines the different treatment types available at the hospital, and how a patient is processed for that treatment type. At any given point during a simulation performed by the system 100, the patient occupies a bed of a particular treatment type. The treatment types are each represented by a row on the treatment sheet, which specifies a therapy script for the treatment type. The therapy script defines the rules for and controls the patient's progress through a sequence of steps called therapies. The therapies are each clinical or non-clinical procedures or steps for a particular treatment type, eg intensive care. For each patient, a state variable is allocated that tracks the current therapy for that patient. Branching and looping can occur within a therapy script. Figure 5 shows an extract from a treatments sheet showing the first seven therapy steps. 3. A scripts sheet includes the most complex procedural scripts of the system 100. The scripts included in this sheet are able to modify the underlying configuration values stored in the database 216 dynamically when a simulation is performed. . These control scripts enable any number of cyclic or calendar synchronised threads to be started. Each thread is then able to independently synchronise events with the virtual calendar and clock. All the events created by these threads are managed by the event management module 202. By adjusting enable and disable flags and configuration data held in the database 216, the scripts can open and close beds, change theatre schedules and enable and disable patient arrival streams, etc. The scripts are global and do not address the progress of individual patients. The scripts are able to perform branching, looping, subroutine calls and thread creation and destruction. The scripts sheet of the configuration module 104 adopts the convention of providing user meaningful data values for the scripts on the right of the sheet and defines a translation proces's that produces numeric procedural script code on the left of the sheet for the command interpreter 206.

An arrivals sheet of the configuration module 104 defines one or more patient entry or arrival streams. More than one stream is used if it is considered necessary to separately control the rate of arrival of distinct groups of patients, or to isolate a particular group of patients for the assignment of attributes. For each stream, the arrivals sheet specifies the patients in the stream, and their arrival pattern. The arrival pattern is variable reflecting the instantaneous frequency of arrival appropriate to the current value of the virtual calendar and the time of day. Factors associated with trend, season, day of week and time of day are superimposed to calculate the instantaneous frequency of arrival. Also associated with each entry stream is a point of entry to the hospital and a pointer to the root of one of the patient attribute assignment trees. For example, if the stream is an elective surgery stream, then the point of entry is the addition of the patient to an elective surgery waiting list. Ambulatory Emergency patients would normally enter via the emergency waiting room and be allocated attributes typical of such patients. The following parameters are also specified in the sheet for each arrival stream and are used to adjust behaviour of the stream. (i) The annual number of patients that arrive in a defined base year. (ii) A central date of the base year that will be used by the system as the base date from which to extrapolate the growth trend associated with this stream to the virtual date of the simulation. (iii) The annual growth rate of the stream, expressed as a percentage per annum, (iv) Seasonal cycle of arrivals by week or by month of the year (v) The daily cycle of arrivals by day of the week, (vi) The hourly cycle of arrivals by hour of the day.

Each arrival cycle is expressed as a string of fractions where each fraction expresses the proportion of the average that is contained in that period of the cycle and the average value of all the fractions in the string is 1.0. Eg the sequence 0.75, 1.5, 0.75 is the string for a three period cycle where the rate of activity for the second period is double that for the first and third. The string of fractions for each cycle is stored on a single row of a cycles sheet of the configuration module 104 and the cycle parameters on the arrivals sheet refer to the relevant row on the cycle sheet.

The above parameter data of the configuration module 104 is used to adjust the interval between successive arrivals for each stream, as the interval is recalculated based on the data and using the virtual date and time maintained for the simulation run by the simulator 102. The simulator 102 is also able to apply a random variation to adjust the intervals, in addition to using the defined parameters, for the patient arrivals in each stream. The process produces a result where for a given stream, patient arrival is random and unpredictable but the instantaneous frequency of arrival varies constantly to mimic the real world with respect to times and dates. The sum of all arrivals in a virtual year will closely approximate the trend adjusted base demand. Changing the base demand adjusts the scale of the patient flow while retaining the same relative cyclic patterns. Figure 6 shows a sample extracted from an arrivals sheet.

An attributes sheet of the configuration module 104 controls how the attribute assignment process is performed by the simulator 102 for each patient in an entry stream. The sheet also importantly defines a number of assignment trees used by the process to assign the attributes stochastically. The assignment process is called by the event management module 202 at the time of admission and the following six attributes are assigned to each patient: (i) a medical condition code, being one of the medical condition codes included in a condition sheet of the configuration module 104; (ii) an admitting clinical unit, being one of the units listed in a unit sheet of the configuration module 104; (iii) a treatment plan, being one of the plans of the plan sheet discussed previously; (iv) the gender of the patient; (v) the age of the patient; and (vi) a discharge destination, being one of the destinations listed in a destination sheet of the configuration module 104.

The attribute assignment process for a patient commences at the root of a particular assignment tree and in the process of traversing the tree each of the six patient attributes will be assigned. The structure of each tree determines the sequence of allocation and the number of steps required. Each tree can have up to six levels as would be required if each of the six attributes was separately allocated. The allocation proceeds from the root to a leaf of the tree, at which the assignment process is complete. Attributes are assigned at a fork or a leaf of the tree. At each fork in the tree, the command interpreter 206 executes a navigation process based on randomly generated variables and weighting factors, which may take into account other data associated with the patient, to determine the next branch to be followed, ie the traversal route that is to be taken by the patient.

The assignment process effectively allocates an unpredictable combination of attributes for each patient. However, each tree can be allocated to a subset of the total population of admitted patients, and with a sufficiently large population, the attribute mix allocated by each entry point to the patients of a given stream approaches a designated proportion and distribution of attributes representing an accurate profile of the patient population in the entry streams. The assignment is effectively specified so as to achieve a desired distribution across the patient population.

A cluster sheet of the configuration module 104 designates the bed or beds that belongs to each cluster. A cluster may have as little as one bed or may comprise an entire hospital. A cluster is associated with a treatment type and also defined with the cluster is preference data regarding the patients who may occupy the beds of the cluster and various operational parameters. The parameters for a cluster include: (i) Ward (ii) Treatment type (iii) Bed count (iv) Discharge time window (v) Bed turnaround time (vi) Clinical unit occupancy preferences and exclusions

A sessions sheet of the configuration module 104 defines a schedule of theatre sessions, particularly those that might be used for elective procedures. For example, a 4 week rotating schedule of theatre sessions for theatres and surgeons can be specified. For each session, a time of day, length of the session, surgeon and procedure list or queue from which the patients may be drawn, are specified. The sessions can be used for day procedures or overnight patients. Treatment plans allow surgical sessions for same day patients, day of surgery electives and prior day elective admissions, and finally for emergency patients. Sessions are allocated to patients, in a similar manner as beds are allocated, using therapy scripting to manage the patient flow. Figure 7 shows an extract of the key columns on a session sheet showing the first three days of the cycle.

A list sheet of the configuration module 104 defines the lists that are to be maintained, for elective procedures performed by the hospital. An arrivals stream associated with a list is able to determine the rate at which a list increases, and similarly the schedule of elective procedure sessions is able to be used to determine the rate at which list is adjusted.

A surgeon's sheet of the configuration module 104 provides a list of surgeons available for allocation to sessions. Detailed data on each surgeon is included in the sheet, such as availability data.

A units sheet of the configuration module 104 is used to define all of the clinical units of the hospital. Key unit parameters specify the boarder management policy for the unit and the image that will represent patients for the unit.

Similarly, a wards sheet of the configuration module 104 allows wards to be listed. A ward designation is not required for operation of the simulation, but the allocation of clusters to wards provides a bridge to the real world that allows an operator or user of the system 100 to work with familiar entities.

A calendar sheet provides a table of calendar data that is used by the simulator 102 to provide a virtual calendar which is used to define when events are triggered. The virtual calendar is used by the event management module 202.

The configuration module 104 also includes layout and report sheets which specify data for the graphics display module 208, and used to specify the form of the output display that is generated on the visual display 218 during a simulation. For example, patients are displayed represented as human figures in rows representing wards. The colour coding of the figures identifies the clinical unit responsible for the patient and the display changes dynamically as the virtual clock is advanced to show the occupancy status at that particular time. This form of display provides a simple graphic interface which indicates movement of the patients throughout the hospital. Figure 8 shows a static example of the display generated. Each string of patient symbols represents the patients presently occupying all the bed clusters that comprise an individual ward and the colours denote the admitting unit.

The hospital computer system 100 may be implemented in a number of different forms. The modules 202 to 208 of the simulator may be provided by dedicated hardware circuits, such as FPGAs or ASICs. The database server 214 may be provided using MySQL (http://www.mvsql.org^') run on a Linux server. The sheets of the configuration module 104 may also be maintained on the database server 214. The modules 202 to 208 of the simulator 102 can also be implemented in SIMUL8 code (http://www.simul8.com^'), and the sheets of the configuration module 104 provided as spreadsheets in Microsoft Excel format (http://www.microsoft.coin). The SIMUL8 code and the Excel spreadsheets can then be placed on a personal computer, such as that provided by IBM corporation (http://www.ibm.com), with a standard OS, such as Windows XP or Linux, to provide the system 100.

Once the configuration module 104 has been finalised, a simulation can then be run on the simulator 102. At the commencement of each simulation run, as shown in Figure 3, the command interpreter 206 builds the run time simulation database 216 using the configuration module 104 and establishes the initial state for all the run time variables and subsystems. Initialisation (302) includes the following: (i) Set the virtual starting date for the simulation run (ii) Each active patient arrival stream is initialised by calculating the arrival frequency for the starting date and time and scheduling the first arrival event, (iii) The operating theatre schedule is triggered so that the first time the day of the week matches the day of the first session in the schedule, the cyclic session thread will start and will then remain synchronised with the day of the week (iv) Row and column headings of reports are laid out according to the reporting content and layout requirements in the configuration module 104. (v) Queue control structures are established and permanent queues 210 are initialised, (vi) Dynamically managed data repositories are initialised. (vii) The main control script is started as a single thread. The script itself will then control the launch of threads for all the additional cyclic and calendar based scripts required by the configuration module 104. Each thread will run to the point where it is waiting on a scheduled future event (viii) The graphics display is> laid out using the ward names and the display offset values contained on the Ward configuration sheet. (ix) Fast access lookup tables are established for several of the configuration sheets, (x) All available beds in the hospital are initially set to unoccupied. Following initialisation the simulator 102 commences the rest of simulation process, as shown in Figure 3. The first of the future events scheduled during initialisation is triggered and the simulation progresses as a self sustaining sequence of events. Patients begin arriving for the patient streams (304). As each patient is admitted attributes are allocated using the attribute assignment tree associated with the arrival stream. The patient treatment thread is then established and the patient enters the bed allocation process and competes for a bed suitable for the first step in the allocated treatment plan, subject to the existing bed occupancy. Under the control of the patient treatment thread each patient progresses through the steps of their treatment plan (308). At various points in the treatment the progress of the patient will be influenced by other hospital activities.

At the completion of initialisation and preceding the arrival of the first patient, the hospital is empty. The configuration module 104 specifies the warm up period being the virtual time that should elapse before the hospital fills and steady state conditions apply. Reporting (310) and performance measures are suspended during the warm up period.

Bed allocation (308) is a significant factor affecting patient progress. Beds are allocated to a specific treatment type, based on the cluster, and a queue 210 of free beds is maintained for each treatment type that are vacant and are available for occupation. A patient progresses between steps in the allocated plan by the command interpreter 206 issuing a bed request for a bed of the treatment type matching the next step of the plan. If any beds of the requested treatment type are indicated by the free bed queues 210 as being available, then the highest preference bed is allocated and the patient progresses along the allocated plan. If no matching bed is available, then the patient progress is blocked and the patient remains on a bed request queue 210 for the treatment type. The event management module 202 then monitors the bed request and free bed queues 210, until a match occurs. Whilst blocked, the patient variables remain unaltered such that the patient remains in the currently occupied bed until a suitable vacancy occurs.

When the plan step involves surgery the patient will only be admitted to the theatre if beds are available for the post operative plan steps. The therapy scripts are able to specify the timing of downstream bed requests, such as for recovery, ICU and ward beds required after surgery for theatre patients. The therapy script also determines what happens to surgical patients who are unable to enter a suitable theatre session.

Beds that have recently been vacated may take time to be made up, and this length of time is cluster specific and is specified by the data of the cluster sheet. Preference data is used to provide some control to the allocation of beds, and the simulator 102 keeps track of boarders, a boarder being a patient placed in a non-preferred bed. In some circumstances, a boarder may incur an extended length of stay, which is imposed if a therapy script invokes this in a treatment plan step. The system 100 may use different boarder relocation policies. For example, the admitting unit for a patient may require that whilst it allows boarders, they must be relocated to a patient's preferred or home ward when an opportunity arises. If a unit has data specifying a relocation policy and the patient is allocated to a non- preferred cluster, then a further bed request is lodged on behalf of the patient for a bed of the same treatment type and is only satisfied by a vacant bed from the preferred cluster. When a boarder relocation request is satisfied, a patient is able to change clusters, but remains on the same step of the plan and the same therapy of the treatment.

The system 100 provides a simulation modelling tool which utilises data based on patient characteristics, treatment planning decisions, and hospital resource availability to examine the interaction between these factors. The output from a simulation run can be applied to strategic and operational decision making in health care. Strategic decisions can be made in relation to resource allocation decisions and operational decisions regarding policies to address bottlenecks in processes or systems of care. For example, the system 100 can be used to examine: (i) Scheduling of elective procedures. (ii) Resource allocation to manage unpredictable demand, eg for emergency surgery, (iii) Optimal numbers and distributions of beds including resource allocation between subacute and acute care. (iv) Decision rules concerning allocation of types of patients to particular wards. (v) The impact of long stay patients upon resource requirements. (vi) The effectiveness of strategies to reduce the resource impact of long stay patients.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

1. A method executed by a hospital modelling system, including: processing patient data representing a patient and allocating the patient to a treatment plan; and allocating the patient to a bed based on a treatment type of the treatment plan, said bed being from a bed cluster corresponding to said treatment type.

2. A method as claimed in claim 1, wherein said patient data represents a plurality of patients and the processing of the patient data involves producing at least one arrival stream of patients.

3. A method as claimed in claim 2, wherein said arrival stream includes patient arrival data and cycle data for arrival of said patients.

4. A method as claimed in claim 2, wherein said patients are allocated attributes stochastically.

5. A method as claimed in claim 4, wherein said patients are allocated attributes based on traversal of an attribute assignment tree.

6. A method as claimed in claim 2, wherein said patients are allocated attributes including said treatment plan.

7. A method as claimed in claim 4, 5 or 6, wherein said attributes include said treatment plan and at least one of a medical condition code, an admitting clinical unit, gender, age and discharge destination.

8. A method as claimed in claim 1, including allocating state variables to said patient, said state variables representing said treatment plan, the current treatment type, said cluster and a therapy of said current treatment type.

9. A method as claimed in claim 8, wherein said therapy defines a hospital procedure, such as a theatre session.

10. A method as claimed in claim 1, wherein unallocated beds of said cluster are assigned to a free bed queue for said treatment type, and said patient is allocated to a bed from said queue.

11. A method as claimed in claim 10, wherein if no bed is in said free bed queue, the patient is blocked for said treatment type.

12. A method as claimed in claim 11, wherein a blocked patient is allocated to a bed request queue until a bed of said cluster is unallocated.

13. A method as claimed in claim 1, wherein a ward of said hospital includes one or more of said bed cluster.

14. A method as claimed in claim 1, wherein said bed cluster includes one or more beds of said hospital.

15. A method as claimed in claim 2, including generating a display of patients allocated to at least one of said bed cluster over time.

16. A hospital modelling system for performing a method as claimed in any one of the preceding claims.

17. Computer readable media having stored thereon code and data for performing a method as claimed in any one of claims 1 to 15.

18. A hospital modelling system, including: a configuration module including patient data representing at least one patient, bed cluster data representing a bed cluster of one or more beds corresponding to a treatment type, and treatment plan data representing at least one treatment plan including at least one treatment type; and a simulator for processing said patient data and allocating a patient to one of said at least one treatment plan, and allocating the patient to a bed based on a treatment type of the allocated treatment plan.

19. A hospital modelling system as claimed in claim 18, wherein said simulator includes a command interpreter for processing procedural code of said configuration module to dynamically adjust a simulation run by said simulator.

20. A hospital modelling system as claimed in claim 19, wherein said procedural code includes said at least one treatment plan, said at least one treatment type defining a sequence of therapies representing respective hospital procedures, and one or more control scripts for threads of hospital activity.

21. A hospital modelling system as claimed in claim 18, wherein said simulator includes a command interpreter for triggering at least one thread of hospital activity, said thread being respectively for one of a patient arrival stream, a patient, a theatre session, a calendar event, and a cyclic event.

22. A hospital modelling system as claimed in claim 21, including an event management module for processing events of said thread relative to a clock of said system.

23. A hospital modelling system as claimed in claim 22, wherein said patient thread controls processing of said patient based on said treatment plan.

24. A hospital modelling system as claimed in claim 23, including a dynamic memory allocation module for maintaining queues for the event management module for bed requests for said patient and unallocated beds of said bed cluster.

25. A hospital modelling system as claimed in claim 18, wherein said simulator maintains a queue for beds of each bed cluster available for patient allocation and at least one queue for patients awaiting bed allocation, and monitors said queues to perform bed allocation.

26. A hospital modelling system as claimed in claim 18, including a graphics display module for providing a graphic display of said allocating over time.