The technical work in a hospital estates sensing project is the easy part. The difficult part is that a hospital contains several organisations with different mandates, any one of which can stop a project, and none of which is obliged to prioritise yours.
Understanding who they are and what they need is the difference between a proposal that gets built and one that circulates for two years.
Who has to agree, and what each one cares about
Estates and facilities
Usually the sponsor. They care about whether it works, who maintains it, and whether it creates new failure modes they will be called about at three in the morning. Their support is necessary but not sufficient.
IT and information security
The most common point of refusal, and usually for good reason. They are responsible for a network carrying patient data and connected medical devices, and a proposal to add unfamiliar devices is exactly the sort of thing they exist to scrutinise. Expect a security review. Arrive with answers about network segmentation, patching, authentication and data flow, and the conversation goes very differently.
Information governance and the data protection officer
Their question is whether personal data is involved. If your system genuinely only measures temperature, humidity and water, say so clearly and the assessment is short. If it involves occupancy, cameras or anything that could identify staff or patients, expect a full impact assessment — and be aware that occupancy data about identifiable staff has employment relations implications as well as legal ones.
Clinical governance
Only engaged if the system touches patient care, which it should not. The most useful thing you can do is state explicitly in writing that it does not, and why.
Infection prevention and control
Authority over what is installed in and near clinical areas. Covered in infection control and device choice.
Procurement
Public sector procurement rules apply, thresholds trigger formal processes, and framework agreements often determine what you may buy regardless of what you would prefer. Find out the thresholds and the available frameworks before designing a solution around a specific product.
Fire safety and health and safety
Engaged for anything affecting doors, escape routes, emergency lighting or work at height.
The IT security conversation, in advance
This is worth preparing for properly, because it is where most estates technology proposals stall.
Network segmentation. Propose it yourself: a dedicated VLAN for building devices, no route to clinical networks, no route to the internet unless specifically required and justified. Offering this before being asked signals that you understand the concern.
Data flow. Be able to state exactly what leaves the building, to where, and why. A system that processes locally and stores data on premises is dramatically easier to approve than one that sends everything to a vendor's cloud. In the EU, whether data leaves the jurisdiction is a specific question with a specific answer required.
Authentication and access. Individual accounts, no shared credentials, integration with the organisation's directory if possible, multi-factor authentication for anything administrative.
Patching and lifecycle. How are firmware updates delivered, how long is the product supported, what happens when support ends. “We don't know” is a common and fatal answer.
Supplier assurance. Larger organisations have supplier security questionnaires. Ask for one early and give it to the vendor early; it frequently takes weeks.
How to write a proposal that survives
Five things, in this order.
State the problem with evidence. A month of data from a plant room, or a documented failure that this would have caught, beats any description of capability.
State the boundary explicitly. “This system does not connect to clinical networks, does not process personal data, and does not touch any patient pathway.” This single sentence removes most objections before they are raised.
Name the owner. A named role in estates, with time allocated. Unowned systems are refused, and rightly.
Cost it over five years including staff time, maintenance, battery replacement and any subscription. Recurring costs need an identified budget line, and a system with no subscription is significantly easier to approve.
Include the exit. What happens if the supplier fails, if the contract ends, if the equipment is discontinued. Who owns the data and can it be exported.
Buy small, prove it, then expand
The single most effective strategy is to start below the threshold that triggers formal procurement, in a location that engages the fewest stakeholders.
A plant room monitoring project is cheap, involves estates and IT only, touches no patients and no personal data, and can be running in weeks. If it catches one failure — a leak, a chiller degrading, a temperature excursion — you have a documented result that makes the next proposal considerably easier.
Attempting a hospital-wide programme as a first project means engaging every stakeholder simultaneously with no track record, and it is the most common way these initiatives die.
Working with estates contractors and PFI arrangements
One structural complication deserves mention because it catches people out. Many hospital buildings are operated under long-term facilities contracts or private finance arrangements in which the estate is maintained by a contractor rather than directly by the trust or authority. In those buildings, altering anything — including adding a sensor to a plant room wall — may be a contractual variation with a price attached, and the contractor may hold exclusive rights to work on building systems.
Find out early which regime applies to the specific building you are targeting, because it changes the economics completely. A twenty-euro sensor that triggers a variation process is not a twenty-euro sensor. Where such arrangements exist, the productive route is usually to work with the contractor rather than around them, and occasionally to find that they already collect data you can simply be given access to.
Things that reliably cause refusal
- Proposing anything on the clinical network. Immediate and permanent.
- Cloud-only systems with unclear data residency. Particularly where a vendor cannot say where data is stored.
- No named owner.
- Unfunded recurring costs. A first-year pilot with no revenue line for year two will not be extended.
- Consumer equipment in clinical areas. IPC will refuse, correctly.
- Anything implying clinical function. If a supplier's marketing mentions patient monitoring, the proposal acquires clinical governance whether you intended it or not.
- Bypassing IT. A system discovered on the network rather than approved onto it will be removed, and it will make the next attempt considerably harder.
A realistic first year
- Month one: talk to IT security and information governance before choosing anything. Ask what they would need.
- Month two: a small plant room pilot — temperature, humidity, leak detection — on a segmented network, locally processed, with alerts to the estates rota.
- Months three to six: run it, document what it catches, and record the escalation tests.
- Month seven: write up the result and propose extension to the rest of the plant estate and to non-regulated storage.
- Months eight to twelve: expand within the non-clinical estate, and approach water safety and cold chain colleagues separately with their own proposals.
Slower than a supplier will suggest, and considerably more likely to still be running in three years. In a hospital, credibility compounds and shortcuts do not.