Why generic IT observability falls short in medical imaging

When a biomedical engineering department starts thinking seriously about observability, the first temptation is usually the same: "we already have Datadog (or Prometheus, or Splunk) for the rest of the hospital — why not plug in the imaging equipment too?". From the IT side it makes sense. From the clinical side it doesn't work. And it's worth understanding why before sinking six months into an integration that will arrive late anyway.

IT observability measures something else

Datadog, Prometheus, Grafana and the rest are built on three assumptions that hold for generic infrastructure:

• The relevant metrics are quantitative and continuous (CPU, RAM, latency, errors/sec)
• Thresholds are universal or configurable by the ops team
• The criticality of a failure is measured in SLOs and user experience

In an imaging service none of the three hold. Critical metrics are discrete and subsystem-specific — a coldhead degradation pattern is not a number trending up; it's a sequence of events with context. Thresholds are clinical: helium levels in a five-year-old MRI tolerate values that would be alarms in a brand-new one. And criticality is measured in displaced patients, not in SLOs.

The MRI case: where Prometheus drops out

Take a real scenario. A 1.5T MRI in a mid-size clinical group:

• Datadog sees: the DICOM service responds, the host agent is alive, the network to PACS is up. Green.
• The biomedical technician needs: helium level, magnet pressure, compressor cycles over the last 72 hours, cryostat thermal drift, ambient room temperature, coldhead state, internal vendor alerts from the last 24 hours.

The first layer is trivial — standard host metrics. The second does not exist in Datadog. It lives in the vendor's service console, in proprietary formats, accessible only from the physical console or from a vendor endpoint with specific SLAs. Wiring that into Datadog is not "deploying an agent": it's building a parser per vendor, maintaining a mapping of clinical thresholds per model, and translating discrete events into metrics that make sense on a generic dashboard. By the time you have it working, you have rewritten half an imaging-specific platform — on top of a tool that wasn't designed for it.

The three points where generalist observability misses

Three dimensions where a generalist platform fails to close the clinical problem:

• Operating modes: an MRI has modes (idle, scanning, ramping, scheduled maintenance) in which the same values mean different things. Low helium during scheduled service is not an alarm. In normal operation it is. The generalist does not distinguish.
• Structured history: a 12-month equipment audit requires correlating vendor events, clinical software events and human operation. That's a domain model, not a TSDB query.
• Actionable alerts: the biomedical technician doesn't need more alerts — they need alerts with enough context to decide whether to dispatch outside of hours or schedule it for the morning. That requires rules written with clinical judgment, not generic thresholds.

When the generalist does make sense

This is not a rejection of Datadog or Prometheus. They have their place inside the same hospital:

• PACS network infrastructure, yes
• RIS/HIS servers, yes
• Cross-site latency for teleradiology, yes
• Patient portal availability, yes

For that layer, generic observability works perfectly. The layer where it breaks is the clinical equipment one — and that requires a platform designed with domain knowledge.

Conclusion

If your hospital already invests in IT observability, don't throw it away. Keep it for what it does well. But don't expect it to cover the imaging fleet — for that you need a specific layer, with vendor parsers, clinical thresholds and an event model that understands subsystems. The two layers coexist well. Trying to force one to do the other's job is like asking an oscilloscope to take an MRI scan.