Multi-Vendor, Multi-System Integration Without the Busywork: Turning Middleware into a Digital Assistant

Speaker: Joe Emerson, EBME Technical Services Manager, Manchester University NHS Foundation Trust

Why this session mattered

If your team spends more time copy-pasting between dashboards than fixing devices, Joe’s talk will feel painfully familiar. He framed a problem every EBME service now faces: we’re being asked to own more systems (RFID, cybersecurity scanners, device dashboards, EPR integrations, AI/SaMD registers) without more resource—and with data quality risks that can quietly de-schedule safety-critical equipment.

“I’m protective of our data… any small problem can result in medical devices not being serviced or missed off a schedule.”

Joe’s premise: make middleware do the donkey work. Don’t turn clinical engineers into “digital porters.”

The reality we’re in

• Exploding system count: RFID platforms, cyber tools, device dashboards, MES portals—each with its own identifiers and logins.
• Duplicate asset truths: “80,000” assets in the EBME CMMS (e.g., Eqip/EquiP as referenced) plus a second asset universe inside RFID or vendor portals—often unsynchronised.
• Human-factor risk: Daily paper/device checks miss faults that emerge hours later; by the next handover the device may have been unavailable for ~24 hours.

“It’s great having a solution, but you need the resource to log onto it… I’m not a casual browser.”

Joe’s integration pattern: let one platform “rule them all”

Joe piloted a pattern that stitches together three elements:

• Vendor middleware: e.g., Zoll Device Dashboard for networked defibrillators.
• Trust CMMS: Equip (“used in the majority—around 95%—of the NHS,” as stated in the session).
• A routing ‘digital assistant’: MediShout—used to ingest signals/forms and create the right action in the right system (and escalate) without manual re-entry.

What it actually does

1. Low-risk prompts to the right owners
• Example: a defib reports “not checked” for two days or a training/consumables issue.
• MediShout routes to resources/ward teams, not EBME—so clinical engineers aren’t dragged into user issues.
2. High-risk faults → automatic EBME job
• A critical fault appears on the device dashboard.
• MediShout opens a CMMS job with the asset ID, location, fault context—before the ward even knows.
• Outcome: hours saved, fewer missed handovers, earlier loan/replacement.
3. Clinician-reported issues (mobile)
• Staff log a problem once in the MediShout app (photo/scan).
• The platform decides: EBME? IT? Estates? It files to the right queue with the right metadata.
4. Next steps Joe is exploring
• RFID overlay: click an EBME job → open the RFID map at the device’s last seen location.
• Multi-vendor scaling: the same plumbing works for other dashboards and third-party portals.

“We’ve proven we can connect the clinical engineering database, connect a middleware system, and record shouts manually, automatically, and without intervention.”

Governance (and cyber) by design

• Data ownership: EBME remains the system of record; other platforms publish signals, not alternate truths.
• RACI by alert type: user issues (resources/matrons) vs. EBME faults—pre-agreed thresholds and escalation.
• Cyber surface area: Joe argues a single integration layer reduces attack surface versus many point-to-point APIs.

What to copy in your Trust

• Map the flows first: Which alerts should never create EBME work? Which must create an immediate job?
• Standard fields: Asset ID, location, fault class, contact path—so auto-created jobs are attendable.
• Escalation logic: Time-based nudges to resources/wards, then EBME lead, then on-call—codified, not ad-hoc.
• Prepare for RFID: Keep UHF-tag/label standards aligned so location can enrich jobs later.
• Measure it: Mean time to awareness (MTA), response (MTTR), and unplanned downtime pre/post-integration.

NHS alignment