If you were to ask 10 people what “Procurement” means you would quite possibly get 10 different answers. Assuming that we know what it is, why does e-Quip need to do it? After all, all NHS organisations have financial systems in place, like Oracle, PECOS, and plenty more with an extra “e-“, like e-Procurement, e-Tendering. Why does e-Quip need to stick its oar in? The purpose of this article is to answer both of these questions. The bulk of the article describes the process and explains our terminology. At the very end I’ll explain why you need e-Quip to get involved. Unfortunately, it’s a long article, but even so, it really only scratches the surface of the subject. I will be publishing some more in-depth posts very shortly. Although it’s a lengthy article is is pretty basic and touches only on concepts, not details.
So, what is procurement? It’s obviously to do with buying stuff so let’s step back a bit and really simplify what that entails:
- Write a shopping list;
- Go to the market and choose things from the various shops for each item on your list;
- Buy the stuff and take it home;
- Use/eat/drink the stuff.
It’s very likely that this will be a never-ending cycle; once you’ve eaten the sausages, drunk the orange squash and watched the flat-screen TV, the whole lot will probably need to be replaced at some point, for which you will need a shopping list …
I personally use the term Procurement (with a capital P) to describe the general process of buying stuff, so items 2 & 3 clearly fall under this heading. Whether or not you think that writing a shopping list is part of shopping is largely a matter of opinion – perhaps worth a few minutes discussion at the pub but not overly relevant here. You might be involved in the whole of this process or just a small part of it. Let’s translate the analogy into a medical device context and explain the terminology we use in e-Quip.
Write a Shopping List
A shopping list is a set of requirements – a list of what you need. How it gets created and what it looks like depends, in part, on why you are writing the list in the first place. If this is the first time that you are going to the shops, then your list will be generic:
- 6 x Sausages
- 12 x Eggs
- 1 kg Flour
If this is for your regular weekly shop then it might be specific:
- 6 x Tesco Finest Beef Chipolatas
- 12 x Waitrose Farm-Fresh Organic Eggs – Large
- 1 kg McDougall Self-Raising Flour
Of course, your list could be a mixture of both. Get used to seeing these terms: generic and specific – you will be seeing them a lot.
Architectural Briefing – Mostly Generic
The first example is analogous to a new-build facility. The list of requirements is the functional brief for the new building. i.e. a set of documents which broadly specifies “what happens where and what stuff do we need to make it happen”. Simplifying the process dramatically, the brief comprises a mountain of Room Data Sheets. If you put them all together, then that’s your shopping list. Here is a (very old) example of a RDS:
The shopping list itself is the 3rd picture down, the Component Schedule. The really important thing here is that the list of stuff that you need is all generic. Look at the list of equipment required in the sheet above. It is made up of coded items, like:
- 1 x LIG053 – LUMINAIRE, examination, ceiling, adjustable, 1000 lux
- 1 x LIG073 – ILLUMINATED SIGN, “Room in Use”
You might notice that the RDS is heavy on space, environment, fixtures & fittings etc., but light on medical devices. This is a reflection of their original purpose and use by architects and Estates department who don’t really have that much to do with stuff that isn’t nailed down. With any luck, once the architects have done the basics, the briefers, nurse planners etc. get involved and add the kit that you’re interested in. The codes that you see above are known as ADB codes. They are generated by the Activity DataBase briefing and design system which is a de facto UK standard. Because ADB was/is similarly light on medical devices, the planners often make up their own codes. A very common UK convention is to use what people refer to as “900 Series” codes, which basically means that they end with “900”. These ADB codes are well-known to companies that sell stuff to hospitals. The brochure below shows that they even understand the occasional “900 Series” code.
As I mentioned above, your shopping list is the combination of the component schedules from every RDS. In e-Quip we don’t call it a “shopping list” as that has too many letters to fit on a button, we call it a “Bill-of-Quantities“, or BOQ, which does fit on a button. From now on I’ll use the term BOQ.
The BOQ is a list of what ADB (and architects) call “Components“. We can’t call them components in e-Quip because of the possible confusion with spare parts and modules, so we had to invent a new name. For good or ill we chose “Briefed Equipment“. So, LIG053 is an item of Briefed Equipment. If you don’t like the name, don’t worry; to implement Procurement we’ve had to invent loads more terminology that you might hate even more!
In this (very brief) introduction to briefing I haven’t yet mentioned geography, i.e. “where” the stuff is needed. I have said that the BOQ is the combination of the component schedules from each RDS, so all of this stuff is clearly required in specific places. Go back to the sample RDS and you’ll see that the luminaire etc. are needed in room “C0237 – Consulting/Examination Room” in department “00-03 Clinical and Support Spaces“, so architects talk about rooms and departments. Geography is a bit awkward for briefing systems because a room is a theoretical template which can exist in many places – a Treatment Centre, for example, could have 20 “identical” consulting and examination rooms. They’re identical in that they contain the same devices and have the same air conditioning, electrical and heating requirements, etc. but they are in different physical places and can be different shapes and sizes. The designers will take the template room “C0237” and dump 20 copies of it on the hospital floor plan. They might give each one its own code, like “C0237-A“, “C0237-B” etc., or they might have their own numbering system. Are these the same as e-Quip locations? Yes and no! When they eventually get built they might then become e-Quip locations, but briefers and architects have many more rooms than e-Quip has locations. This is just one example of the “granularity problem” which plagues Procurement. In e-Quip you might have a location “A&E“, for example. To an architect this could be several hundred separate rooms, including bays, cabins, staff changing rooms, waiting areas, toilets, … but to you it’s just one location.
In e-Quip we have called this an “Activity Space” – it’s what rooms were called in the early versions of ADB. So, “C0237-A” is an e-Quip Activity Space.
In e-Quip a location is a place within a site. In ADB, rooms occur within a department. There is some historic messiness going on here. The ADB data is a set of guidance issued by the DH based on Health Building Notes, or HBNs. If you look back to the RDS you’ll see a mention of “HBN 00-03 – Clinical and Support Spaces“. It’s no coincidence that the department is “00-03“. Clearly an ADB department is not the same thing as an e-Quip department (service) or site. In practice it doesn’t really matter what the people who produced the brief had in mind when they created the department; it’s just a grouping for rooms. In e-Quip we use the term “Facility“. So, if the activity space “C2037-A” is in the ADB department “SURGICAL OPD Surgical Outpatients”, then e-Quip will have a corresponding Facility.
Important: The output of the brief is the BOQ which is expressed in generic terms. It takes the form:
- Quantity (New / Transferred)
- Briefed Equipment
- Activity Space
- Facility
i.e. what is needed and where it is needed.
Equipment Replacement – Mostly Specific
If this isn’t your first trip to the shops, then the likelihood is that you’re replacing an existing bit of kit. If you are replacing a “Therapy Equipment Diamond High Suction Controller“, then there is a very good chance that you are going to replace it with another “Therapy Equipment Diamond High Suction Controller“. This is an example of a requirements list which is specific (i.e. manufacturer-specific) rather than generic. In this case your BOQ might look like:
- 1 x Welch Allyn Green Series 600 Minor Procedure Light
- 1 x SignalTech SBL77R-195 Indoor Blank-out LED Backlit Sign
This is a different flavour of Procurement. In e-Quip terms, the requirements are models which will already exist in your database. This process is managed by the Capital Bidding process in e-Quip. You can read all about it in this fascinating blog article. If you want to you can create a BOQ from capital bids.
Go to the market and choose things from the various shops for each item on your list
So, we’ve made our shopping list (sorry, BOQ), which is most often a generic list of requirements. Now all we have to do is decide what we are going to buy. This is a complex process so we have deliberately separated “choosing” from “buying” as they are fundamentally different.
This process of choosing what to buy is known as “equipping” and it is essentially the transition from generic to specific. It is done by equipping specialists, not designers or briefers. It is the process of arriving at:
- 1 x Welch Allyn Green Series 600 Minor Procedure Light
- 1 x SignalTech SBL77R-195 Indoor Blank-out LED Back-lit Sign
having started with:
- 1 x LIG053 – LUMINAIRE, examination, ceiling, adjustable, 1000 lux
- 1 x LIG073 – ILLUMINATED SIGN, “Room in Use”
This is stage at which equipment managers will often get involved. After all, you probably know more about these devices than anyone else. Who better to advise on what to buy.
You can see that the starting point is defined in terms of briefed equipment and the output will be defined in terms of models. How you make this transition will vary with a huge number of factors, such as price, availability, clinical need and risk, maintenance considerations, user training etc. One approach is to buy from your brother-in-law who has recently made a bit of a killing in the luminaire market, while a more conventional alternative might be to use competitive tendering. This involves creating a specification which is sent to suppliers who then respond by listing the specific devices that they offer which can meet the details of the specification.
This involves some new e-Quip entities:
- Generic Specifications
- Tenders
- Quotations
Why do we need specifications? Couldn’t we just say, “how much for a LIG053”? For some things (including, coincidentally, LIG053), yes you can. The brochure shown above basically says that if you need a LIG053, then a “Daray Excel” is just the ticket. Google LIG053 and you’ll find plenty of alternatives. While this might be the case for simple stuff like lights, taps, doors, was basins etc., but not for more complex medical devices. The BOQ might say that you need “100 x INF001 PUMP, Infusion”. Suppliers are going to need a bit more to go on than that! Asking Codan for a quote for a “PUMP, Infusion” is a bit like asking Ford for a quote for a “CAR, Motor”.
I’ve said that equipping is the transition between generic and specific. The next more-specific level on from briefed equipment is a generic specification. It is generic in that it is not manufacturer-specific, but it is more detailed than an ADB code.
Where does the detailed technical stuff (voltage, lumens, power consumption etc.) go? This is best held in attached documents as you will almost certainly be preparing these using Word, PDF or something similar.
So, we have inched one painful step along the route from generic to specific:
You might be getting the idea here that left = generic, right = specific. As we move across the screen we are getting more and more specific, and closer to our journey’s end. From now on I’ll only show the right hand side of the BOQ because you would need a very wide screen to see the whole lot, and the left is always going to stay the same.
In e-Quip, specifications exist to support tenders. Just like spare parts are line items in orders in “conventional” e-Quip, generic specifications are line items in tenders.
This very simple tender will have a single line item:
Now we can update our BOQ again to indicate that we have published a tender for these items.
Hmm, looks like we could do with a Status column here to say something like, “On Tender” so everyone can see what’s going on.
Having told the world that we would like to buy something we might reasonably expect a response or two to flood in. We call these “Quotations“. These are always expressed in manufacturer-specific terminology, i.e. as models. Imagine that you are using spreadsheets to manage this process. Shared spreadsheets basically don’t work reliably, especially if they’re big, so you give everyone involved a copy of the spreadsheet. So far so good. Then a quotation arrives from Daray Medical. Whoever is in charge of lighting adds a few columns, say Supplier, Model and Price. Then a quote arrives from Brandon Medical, and some more columns get added. Remember this, I’ll revisit it later.
We can see all of the quotations from the tender screen:
Now someone needs to make a decision. I’m afraid e-Quip can’t help you there. Let’s say that you decide to go with the Daray quotation. We can now get even more specific because we know the actual model that we will be buying. We also have a firm price.
If we had a Status column (which we do) we could now update these 2 rows to say that we have accepted a quotation and are ready to place an order.
This is a simple example of equipping. We have progressed from Briefed Equipment (generic) to Model (specific) by means of Generic Specifications, Tenders and Quotations. Of course, it doesn’t always happen like that. You might for example get all of the suppliers to present their products and then choose a supplier, but possibly leave the quotations and selection of models until later on in the project. Either way, the end result is the same – a list of models that you need to buy.
Buy the stuff and take it home
You can see by now that the whole process is getting quite complex, which means that the software needs to be correspondingly complex. We’ve had to invent some new terms along the way, like briefed equipment, activity spaces, facilities etc. As we move on to actually buying something, let’s invent one more – “procurement” (with a small “p”). This is the name we give to the process of actually buying a specific thing from a specific company. i.e. raising orders (or requisitions, depending on your viewpoint) and receipting the deliveries. So Procurement is the whole kit and/or caboodle, while procurement is just raising orders and accepting deliveries. Of course, this is terminology that we have dreamt up – you say “tomato”, we say “edible, often red, berry of the nightshade Solanum lycopersicum”. (thanks Wiki). What’s in a name? A tomato by any other name would smell as sweet (thanks Shakespeare).
You will have seen spare part orders in e-Quip, where the line items are spare parts. Equipment orders are virtually the same, except the line items are models.
So, our BOQ marches relentlessly from left to right.
Likewise, you will have seen deliveries for spare part orders. It should not come as a great surprise to you to learn that just like there are equipment orders, there are also equipment deliveries. They have lots of the features of spare part deliveries, like split and incomplete deliveries.
Let’s have another look at our BOQ. To make it fit on the screen I’ll show it in several slices:
…
…
I have skipped over many complications and just looked at a very simple case. Of course, Procurement can be far more complex than this. But, in this extremely simple example, we have eventually achieved what we set out to do and bought something. Hurrah!
Use/Eat/Drink the Stuff
Now that both (P)rocurement and (p)rocurement are finished, we have some shiny new devices – Hooray for us! What are we going to do with them? In our long slog from generic to specific, is “model” the end of the line? It may well be the end of one person’s line, but it’s the start of someone else’s – probably yours if you’re an equipment manager. We have two brand new “Excel C” examination lamps, fresh from Santa’s elves. These will need to be added to e-Quip as equipment records and their serial numbers recorded. Commissioning jobs will need to be raised and if they are replacing two old lights, then those will need to be decommissioned.
So “Model” isn’t quite as specific as you can get. We will need an extra column for “Equipment No“. We will have arrived at a real, tangible, identifiable asset. We must have finished – surely that is as far as you can go. Er, sorry, but no. In some cases this is as simple as it seems, but what if we had a BOQ line like:
- 2 x LIG053 – LUMINAIRE, examination, ceiling, adjustable, 1000 lux
i.e. a single line with a quantity greater than 1. Of course, you could add a couple more columns to your spreadsheet, like “Serial No 1“, “Serial No 2“, just like you did earlier with “Quotation 1“, “Price 1“, “Quotation 2“, “Price 2” etc. Remember this spreadsheet; it will come back to haunt us.
How about a line like:
- 1 x MON001 – Patient Monitor
That is surely about as simple as you can imagine. How could this possibly get more complicated? Remember the “granularity problem”? It doesn’t just apply to locations, but annoyingly interferes with quantities as well. What if, when you buy this from Philips you actually buy:
- 1 x M8010A IntelliVue MP90 Monitor
- 1 x M3001A Multi-Measurement Server
- 1 x M3015A Micro-Stream CO2 Extension
- 1 x M3012A Hemodynamics Extension
But if you buy it from Drager then you buy:
- 1 x M540 Infinity Monitor
Remember that one row in your BOQ doesn’t necessarily result in one equipment record in e-Quip, even if the quantity is one.
BTW: please Drager or Philips, don’t sue me! I’m just plucking names out of thin air (well, the internet actually) to try to make a point.
There are so many more complications but we can’t consider them all here. Perhaps a common one is that the briefer (bless his/her cotton/acrylic socks) uses the same code several times when he/her actually means something different. A good example is:
- Recovery – 6 x MON001 Patient Monitor
- Theatre 1 – 1 x MON001 Patient Monitor
- Theatre 2 – 1 x MON001 Patient Monitor
- …
Here we have a lazy and/or silly briefer who knows that you need monitors in the operating theatres and in recovery. Now you know and I know that the monitors in theatres are not the same as monitors in recovery, but the briefer may or may not be aware of this distinction. Perhaps he is cleverer than we suspect but can’t be bothered to find the correct ADB code, or to invent yet another 900 series code. Either way, a grown-up, or at least an equipper, will have to look at the combination of requirement and location and work out that these are actually different devices. Heaven forbid that you change the BOQ; that has been signed off by investment bankers and goodness knows who else. Clearly, we can solve this problem by associating a different generic specification with each BOQ line. Things are not quite so simple if some Herbert has specified:
- 8 x MON001 Patient Monitor
We are going to have to turn this into at least two lines, one for 2 theatre monitors and 1 for 6 recovery monitors. I’ll defer how we handle this for another article.
What has any of this got to do with e-Quip?
Ok, so you know what Procurement is (or at least, you know what, in our view, Procurement is), but why does e-Quip need to get involved? For Goodness’s sake, enough with the computer systems, already! It might surprise you to know that e-Quip was originally an equipping system. Long before it had equipment, jobs and spare parts, it had BOQs, tenders, specifications, quotations etc. The name “e-Quip” was actually suggested by one of our equipping users. It was only many years later that we wrote a medical device asset-management system. It was based on the same application framework as e-Quip and so we called it “e-Quip AM” (for Asset Management). To differentiate between the two products, we started referring to the original e-Quip as “e-Quip PM” (for Procurement Management). The AM & PM does not signify that one was written in a morning and the other in an afternoon!
For several years our procurement and asset-management customers were happily unaware of each others’ existence, and they each called their software “e-Quip“. This was not a problem because there was virtually no overlap between the two groups. While the users didn’t overlap, the functionality certainly did. Both applications have their own data sets but both also have things like lists of brands, models, categories, suppliers, locations, people etc. Having two separate applications resulted in a lot of importing and exporting data between them. A couple of years ago we took the decision to merge the two products together, so now there is a single product, naturally called e-Quip, but with licensing options which turn various features on and off.
Anyhoo – I’m digressing. What is e-Quip bringing to the party?
1. Reduce Data Double Entry
We have a complex, multi-step process here where the output of one step is seldom, if ever, passed on to its successor. The design and briefing team will produce the BOQs that identify what is needed. This is then all re-entered into different systems by the equipping team. They in turn pass their results on to the procurement team. Once something is actually purchased, the EBME or Medical Physics users then have to re-enter the same information all over again. I have seen more than one scheme where the output of the brief was given to the equippers as a PDF document!
This is completely unnecessary. e-Quip is written by Integra (e-Quip) Ltd. We chose that name because we have always specialised in integration. It is now possible for the requirements to be entered just once, at the start of the project, and then to be passed along the chain, eventually resulting in inventory and job records being created automatically, with no re-entry of data.
2. Process Management
This is the main reason that we wrote (the original) e-Quip in the first place. Imagine that your Trust is building some new facility, perhaps a Treatment Centre. The briefing team have done their work and produced a mountain of room data sheets saying exactly what goes where. So, you put all of the component schedules from all of these rooms together into one big BOQ and off you go! Well, where do you go, exactly? What do you do first? How do you know? How do you know what you’ve done so far, or what to do next? Let’s say you’re 3 months into the project when you bump into your boss in the corridor and he says, “how are we doing?”. Apart from vowing to keep a better lookout when loitering in corridors, what do you say?
Here’s a couple of sample answers:
- “Well, for Radiology we’re just confirming the technical specifications and expect to be going out to tender next month. For the patient monitors we’ve been out to tender and we’ve had 3 responses so far. It looks like a choice between Philips and GE. All of the bedhead services, suction controllers etc. have been ordered and half should be delivered in January with the remainder planned for next April. The specs for Pathology were signed off last week and we’ll be publishing the draft tender next week. You’ll get an email when it’s ready. For the equipment which we have to provide we’re within 1% of our planned budget. All of the stuff fitted by the builders has been ordered. …”.
- “Er, glad you asked! I’ll get everyone to send me their copies of their spreadsheets then I’ll merge them together and get back to you with some details. We did try using a shared spreadsheet but it kept crashing and getting corrupted. I’ll get the Finance team to email me the summaries of orders raised since last month and I’ll reconcile that with the spreadsheets to find out where we are. Bill’s looking after patient monitors and he’s on annual leave, so I’ll have to get back to about that”.
- Remember that spreadsheet that you sent out to everyone- the one where everyone added columns for things like multiple suppliers, quotes and prices?
- Good luck trying to merge that lot when they’ve all got different columns!
Clearly we’re all going for option 1, but where do you get this information from? Your e-procurement and e-tendering systems aren’t going to be much help. They only know what you’ve actually ordered and they don’t link back to your shopping list, so they don’t know why you bought stuff. They can tell you how many tenders you’ve created and who has responded, but they know nothing about the ones you haven’t created yet. They can’t help you decide what needs to go out to tender next. If your shopping list is in 50 different spreadsheets, all being modified independently, then basically you are not in a position to know how you’re doing. You will end up a) having lots of meetings to try to get to grips with how you’re doing and b) be more careful the next time you’re in the corridor.
But, if you get away from spreadsheets, all of this information is in the BOQ. Add a status column and the BOQ can tell you everything you need to know. The BOQ, along with the status of each item, is the heart of the (P)rocurement process. Procurement management is essentially BOQ management, and managing a BOQ in e-Quip is as flexible and as simple as managing a list of jobs.