First of all, what exactly is the “capital bidding process“? Essentially this is the process which starts with someone requesting the purchase of a medical device and ends with the commissioning of whatever is purchased. The term may be somewhat of a misnomer since there is no real need for the request to relate to a capital purchase. The word “bid” here is meant in its non-commercial meaning, “to attempt” (like Lex Luthor’s bid for world domination) rather than “to offer“, although that interpretation does help to capture the notion that this is often a competitive process. There may be many requests for equipment purchases but without unlimited funding not all of those requests will necessarily be satisfied.

Support for capital bidding will be introduced in version 3.9.0. It is intended that the first stage of the process will have a browser-based interface because the requests for new devices can originate anywhere in the organisation. The subsequent stages (evaluating and comparing the relative merits of the requests, recording those decisions and the reasons for them, through to eventual commissioning) will be managed via the traditional e-Quip desktop application.

SIGs

This functionality is both complex and varied. Although most hospitals have a broadly similar process there are significant differences. The main point that they seem to have in common is that at the moment the process is managed used spreadsheets and emails. In order to work out how to map these processes into a software model that we can implement in e-Quip we have convened a number of Special Interest Groups, or SIGs.

We have had a number of SIG meetings where we have learnt from users what they need the process to do and we have designed the new e-Quip functionality on the results of those meetings. However, this is an on-going process – if you would like to be involved in the design process or would like to attend or even host a SIG meeting, then please let us know as soon as possible.

In the early design stages we are implementing your suggestions solely in the e-Quip desktop application. Once we have broad agreement that the model we have is correct, only then will the browser interface be created and released.

Projects and Bids

Although it can happen that a request for new equipment can occur in isolation, more commonly multiple requests will be made for a particular reason. Perhaps the most common example is annual equipment replacement. Suppose that, in common with many hospitals, every year your hospital or organisation creates a spreadsheet created containing a list of all the devices which need to be replaced, grouped by departments. Let’s suppose you call that spreadsheet “2019 Departmental Equipment Replacement.xls“. You might email that spreadsheet to all department heads and ask that they identify which of those devices they need to replace. In response to that, each department may return the spreadsheet indicating what they would like to replace and why. That spreadsheet would then form the basis of any procurement decisions made.

In this example, all of the requests have one thing in common; they are all related because they originated from “2019 Departmental Equipment Replacement.xls“. Suppose some funds become available as a result of a charitable donation. You might create another spreadsheet called “2020 Macmillan Centre Extension.xls” and send this to the appropriate people. In e-Quip we have modelled this as a Project. To manage this process you would create two projects: “2019 Departmental Equipment Replacement” and “2020 Macmillan Centre Extension“.

Each individual request within a project is called a Bid. i.e. a project will comprise one or more bids. A bid must always be associated with a project which means that even ad hoc requests for single devices require a project to host them.

A bid relates to one or more devices, but these devices must all be for the same model. Suppose that a department needs to replace the following devices:

This would require two bids: one to replace the syringe drivers (x 5) and another for the camera stacks (x2).

This then, is the basic model: projects made up of bids. The bids will be evaluated and some will be approved, some rejected and some may be deferred. The purpose of including support for the capital bidding process in e-Quip is to:

• Record, monitor and manage the device request process;
• To simplify the commissioning of new devices and decommissioning of the items that they are replacing.

The remainder of this article will discuss the process in more detail

Capital Projects

We have seen that a project is simply a container for device requests, or bids. As such they do not themselves have many attributes. The Project Type describes the nature of the project while the Project Status describes its life-cycle.

Bids can be both created, viewed, edited and deleted from within a project, but it is also possible to create commission and decommission requests directly from the project.

Bids

A bid is, as we have seen, a request for one or more devices made as part of a project. Bids are far more complex than projects since they must record:

• General details of the bid
  • key dates, originating department etc.
• Why the bid is being made
• How important the bid is
• What devices are being requested
• Which devices are being replaced, if any

Most of the fields on the first tab are self-explanatory, but it is worth explaining the differences between the three priority values.

Priority: This is the bidder’s assessment of how important the bid is

Calculated Priority: This is a numeric value which is calculated automatically by the system using any methodology that you choose, as long as the methodology can be expressed in a deterministic way. You might have a formula along the lines of:

P = Y x (C + M)

Where:

Y = Years Past End-of-Life

C = Annual Contract Cost

M = SUM(Maintenance Costs) since End-of-Life

Clinical Priority: How important is the provision of the device(s) to the clinical functioning of the department.

The Device Details tab describes:

• Where the equipment is required
• The  device being replaced
• The  device required
• The training impacts of the purchase

The first part is simple:

Different Trusts have different requirements when it comes to identifying the devices to be replaced. Of course, this only applies to bids which relate to equipment replacement, which will not always be the case. Some organisations insist on the redundant device(s) being explicitly identified, while others allow a textual description. The bid screen allows either or both methods, as shown below:

If the actual equipment number(s) is/are known, then one should be entered in the field “Replacement for” and the remainder listed on the Device List tab.

In the example above, notice that selecting a device in the “Replacement for” field has automatically populated the brand, model and category fields of the Device(s) REQUIRED section below it. The device selected is a “STORZ TeleCam DX PAL” model. On the model screen it is possible to specify a default replacement. For the DX PAL this is:

This selection can be overridden if an alternative device is required.

In this example, 2 camera stacks are being replaced. One is specified in the “Replacement for” field while the other should be entered on the Device List tab.

Just as there are two ways of identifying the items being replaced, so there are an analogous two ways of specifying the devices which are to be purchased: either as free text or as a model. The example above shows a model while below we see a request in a textual form.

So, the user has stated what they would like and the items that are being replaced (if applicable). The final section of the screen highlights any training implications that the purchase might have.

The Financial tab is mostly self-explanatory and describes the financial implications of the proposed purchase.

Note the inclusion of two budgets for each type of expenditure: Cost Centre & Subjective. This is a new way of managing budgets which is being introduced across the whole of e-Quip to more-closely model the way in which budgets are managed within the NHS. Both the Cost Centre & Subjective are budget lookups, but while the Cost Centre budget identifies “who” is paying, the Subjective budget identifies the type of expenditure.

The Device List tab identifies additional devices which are being replaced if there are more than one. This sub-list is filtered by the model which appears on the Device Details tab.

Note the two checkboxes in the list:

Will be Surrendered: if ticked this indicates that the device will not be retained after its replacement has been purchased.

Possessed: Not a reference to demonic possession, but used to indicate that the bidder is currently in possession of the device or knows where it can be found.

The Evaluation Process

So, a project has been created and published, which announces to device users that device requests are being invited. The users respond by preparing and then submitting bids which outline their requirements. There may be an intermediate stage between bid preparation in which a bid may Submitted for Clarification. They may be unsure of exactly what is being replaced, or the choices of model available or may have some other questions. Submitting a bid for clarification passes the bid on to the appropriate person/department to provide that information. Once a bid has been submitted it can no longer be modified by the submitter.

Each of the bids will then be assessed by the appropriate person or group. It may be that a more-senior manager might review the bids submitted by his or her department or ward. At this stage bids can be modified to change priorities, status, quantities etc. There may be several stages of evaluation, perhaps with the bids then progressing to the Head of a Division, where again bids can be modified.

Essentially, this part of the evaluation process is there to ensure that the only requests which go forwards for  consideration for purchase are the ones which have been approved by the senior manager who has the ultimate responsibility for equipment purchases. Just because a bid makes it to this stage does not mean that the device(s) will actually be purchased.

Above we see an example where 5 bids are submitted from several departments within a Division. The management team prioritise these, reject 2 of the bids and modify the number of devices requested. The three remaining bids are then passed to the Divisional Director who rejects 1 of them and reduces the quantities of the others. These are the bids that are submitted for financial approval.

There will be some group or committee which is responsible for making value-judgements about the merits of each bid and will weigh these against the money available and the services that the hospital must provide. The output from this will be a number of purchasing decisions. What happens next depends on how you manage equipment procurement. If you do not use the procurement features of e-Quip then you simple pass the list of approved bids to your procurement team for them to manage.

Using e-Quip to Manage Procurement

e-Quip actually includes a powerful set of procurement tools which manage the process from the initial request for a device, through competitive tendering, recording of quotes received, placing orders and receipting deliveries. This is separate from the asset management features of e-Quip and is available as a chargeable option. It is not widely used in England since most NHS Trusts require equipment orders to be raised within their approved purchasing systems. It is, however, used in Scotland, Ireland and the private sector where these constraints do not arise. This product is fully-integrated with e-Quip and is informally known as e-Quip PM (Procurement Management).

In e-Quip PM the list of devices to be purchased are held in a BOQ, or “Bill of Quantities“. It is possible from a capital project to automatically populate a BOQ from all of the approved bids within the project.

A full description of e-Quip’s procurement features is beyond the scope of this article. It includes entities such as Generic Specifications, Tenders, Quotations, Orders & Deliveries.

Commissioning and Decommissioning

We have come a long way since starting with a group of requests fro equipment from device users. Somehow or other, whether you use e-Quip’s procurement features or not, a number of new devices will be delivered and several redundant devices will need to be decommissioned. Rather than having to re-enter all of this data manually, it can all be created directly from the project.

Below is an example of a very simple project which contains just one approved bid, which is for 2 Olympus Camera Stacks.

Let’s see what happens when we click the Create Commission Requests from Approved Bids button.

A message is displayed saying that 1 commission request has been created, which ties up with the project only holding 1 approved bid. Let’s look at the commission request screen. We indeed see a new commission request and notice that some of the bid details have been copied to it:

It does not really need an example to demonstrate that clicking the Create Decommission Requests from Approved Bids button does the same thing, creating instead a decommission request.

This concludes our brief tour around the new capital bidding functionality, which will be introduced in version 3.9.0. As already mentioned, this is very much a work-in-progress. Any suggestions or feedback that you may have will be gratefully received.