Resources
Implementation guide
Most implementations in this category fail in a specific and avoidable way: the organisation decides to get the data right first, discovers that takes six months, and by the time anything is switched on the sponsor has moved role and the momentum is gone. This guide argues for the opposite sequence, and explains why.
- Hospital operations
- Biomedical engineering
- Quality and compliance
What is an equipment management implementation?
Definition
Equipment management implementation
Implementation is importing the register you already have, putting identifiers on the equipment that matters most, configuring your own rules, and getting the people who do the work using it, in that order and starting well before the data is clean.
Notice what is not in that definition: a data-cleansing project, a process-redesign workstream, and a big-bang launch. Those are the three things most commonly scheduled first and they are the three most reliable ways to arrive at month nine with nothing running.
The reason is not that data quality does not matter. It is that a register becomes accurate through use, not through effort. Every scan by a technician doing a job they were doing anyway is a confirmation. Waiting to be perfect means paying for a discovery exercise that the first month of ordinary work would have given you for free.
How to sequence a rollout that survives contact with a hospital
Import, label the equipment that hurts, configure your rules, put it in technicians' hands, and widen only once a rhythm exists.
- 1
Import the register you have, imperfections included
Whatever spreadsheet exists today, import it. It will be wrong in places, and that is fine, because the alternative is a cleansing project that delays every other benefit behind it. Import is an afternoon. Getting a spreadsheet perfect first is the most common way this work stalls for a year.
- 2
Put codes on the equipment where failure hurts most
Not the whole estate. The devices where an unreported fault is genuinely expensive or unsafe. Put the label somewhere a person holding a phone can actually reach, which is a different place from wherever is convenient at printing time. Every estate learns that once.
- 3
Configure your rules, and only yours
Intervals, procedures, limits, approval thresholds. These are your decisions and the platform ships none of them. Expect this to be the step that takes real thought, because it is the step where somebody has to say out loud what the policy actually is, and frequently that has never been written down.
- 4
Give technicians the mobile surface the same week
Not after the register is complete. The technician standing in front of a real device is the highest-quality data source in the organisation, and their scans are what make the register true. Deploying them late means paying for an audit you could have had for nothing.
- 5
Let the first month correct the plan
It will surface what the plan got wrong: devices nobody knew about, locations that were fiction, a workflow that does not match the ward. This is the point of starting small. The information is worth more than the tidiness it costs.
- 6
Widen when there is a reason, not when the plan says
The second site or department is substantially faster, because the configuration is mostly reusable and you now have people internally who know what good looks like. Widening on a schedule rather than on readiness is how a pilot becomes a programme nobody believes in.
Why the pilot should be your worst site, not your best
Because a pilot where everything goes well tells you what you already assumed, and the messy site tells you what the rollout actually costs.
The instinct is to pilot somewhere motivated and well-organised, because it maximises the chance of a success story. It also guarantees the success story is not transferable. You learn what happens when the register is decent, the team is engaged and the equipment is documented, and then you roll out to a site where none of that is true and discover the real cost with four sites watching.
The awkward site is the honest test. If it works where the estate is messiest and the team is most sceptical, it works. If it does not, you have learned that in one place, cheaply, with the option to change approach before anyone else is committed.
This is a genuinely uncomfortable recommendation and most organisations do not take it. The compromise that works nearly as well: pilot somewhere ordinary rather than somewhere exceptional, and be honest with yourself about which one you picked.
Where implementations actually go wrong
Four failure modes, none of them technical, all of them predictable enough to plan around.
Nobody owns the register
Scans and data-quality scans surface what is wrong; a person still has to care that it is wrong. A register owned by nobody decays at exactly the rate you would expect, and no amount of tooling substitutes for accountability.
The rules were never actually decided
Configuration forces a decision that was previously ambiguous: how often, what limit, who approves above what value. Expect this to stall, and resolve it as a decision with a name against it rather than a default somebody picked to unblock a sprint.
It was launched to managers, not to the frontline
If reporting a fault is not faster than the workaround, staff will use the workaround, and your fault log will record only the problems annoying enough to overcome friction. That is not a training problem, it is arithmetic.
Security review came last
By contract stage the clinical stakeholders are invested and the timeline is public, which is the worst possible moment to discover a disqualifying gap. Ask in week one, when the answer can still change the decision cheaply.
When to expect the benefit, honestly
Fault reporting improves in week one. The register becomes trustworthy over a quarter. The financial argument lands at about six months, and not before.
The frontline change is immediate and small: somebody scans a code instead of finding out who to call, and gets a reference instead of silence. That is real on day one and it is what earns the goodwill you will need for everything else.
The register takes a quarter, because it becomes true through use. Expect the first month to look worse rather than better: you will discover devices you did not know about and locations that were wrong. That is the system working, though it rarely feels like it at the time, and it is worth warning your sponsor before it happens rather than explaining it afterwards.
The financial argument is the slowest and the most valuable. It needs enough priced downtime intervals and enough accumulated cost to be more than an anecdote. Six months is realistic. Anyone promising a board-ready cost case in the first quarter is promising you an extrapolation, and the finance director will treat it as one.
What we cannot help with, and will not pretend to
We do not supply intervals, limits, thresholds or approval policies, so the configuration step needs your qualified staff and cannot be outsourced to us or to a default. There is no migration service, no professional-services team and no named connector to your existing systems: imports cover seven registers and webhooks reach anything that accepts one. If your plan depends on a vendor doing the thinking about your clinical rules, that plan does not work with us, and probably should not work with anyone.
Questions
Should we clean our asset data before importing it?
No, and this is the most consequential recommendation here. Import what you have. A register becomes accurate through use rather than through effort: every scan by a technician doing a job anyway is a free confirmation. Cleansing first delays every other benefit behind a six-month project, and it is the most common way this work stalls for a year.
Which site should we pilot at?
The awkward one. A pilot at your best-run site tells you what happens when the register is decent and the team is engaged, which you already assumed. The messiest estate tells you what the rollout actually costs, in one place, cheaply, while you can still change approach. Most organisations do not take this advice; the workable compromise is to pick somewhere ordinary rather than exceptional.
How long before we see a return?
Fault reporting improves in week one. The register becomes trustworthy over about a quarter, and expect the first month to look worse as you discover devices and locations you did not know about. The financial argument needs roughly six months of real intervals and costs. Anyone promising a board-ready cost case in the first quarter is offering an extrapolation.
Do you configure our maintenance intervals for us?
No, and no vendor should. Intervals, limits, thresholds and approval policies are decisions for your qualified staff, your manufacturers and the standards that apply to you. Expect this step to take real thought, because it is where somebody has to state a policy out loud that has frequently never been written down. The platform holds what you decide and enforces it.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us