Field service AI for medical devices: A vendor evaluation checklist

When an imaging system goes down in the middle of the night, your field engineer needs more than a manual. They need help figuring out what’s wrong and what to do next, especially if they’re new to the equipment and the person who knew it best has retired.

That’s where AI should help. But before you buy, you need to know whether it can handle the problems your technicians actually face, not just answer questions in a demo.

Field service AI for medical devices carries a heavier burden than AI anywhere else, because a wrong answer stalls patient care and an undocumented fix adds a regulatory problem to a service problem. To help you compare vendors fairly, here are seven questions for your next meeting, along with the answers Neuron7 gives.

Here are seven questions, ordered from the newest thinking to the most familiar:

1. Does the AI use deterministic or probabilistic reasoning?
2. How do you predict failures on devices that send no data?
3. Does your service guidance leave an FDA audit trail and surface complaints?
4. Does every resolution record hold up in an audit?
5. Does the AI capture what your best technician knows before they retire?
6. When does ROI start, and who does the work?
7. Which customer produced your accuracy and ROI numbers?

‍

Why most AI stalls on regulated equipment

Before we dive into the questions, here's something to consider.

Most AI built for service connects a language model to a knowledge base. It's a reasonable place to start, but on medical equipment it runs into two problems.

• The knowledge goes stale. Articles lag behind product revisions and often contradict each other. The AI repeats the article and misses what your best technician does.
• One approach serves every problem. Finding a root cause and walking through a known repair call for different techniques, so one method rarely serves both well. Generic approaches plateau between 50% and 65% accuracy.

On a patient-critical device, a plateau at that level is a safety issue, so it's worth asking how a vendor gets past it. Neuron7 resolves with 90%+ accuracy across deployments. The first question covers how the AI reasons, since that shapes everything else.

‍

1. Does the AI use deterministic or probabilistic reasoning?

Trick question: the right answer is both. Not every service problem calls for the same kind of thinking. When a fault has a documented fix, your technician needs the same approved procedure every time. When a failure is new, nobody has written the answer yet, so the system has to weigh the evidence and rank the likely causes.

That's the difference between deterministic and probabilistic reasoning. Deterministic reasoning follows known rules, so the same input returns the same output. Probabilistic reasoning scores likelihoods from patterns in past cases, which is what you need for unfamiliar faults and for predicting what fails next.

A tool built on one approach has to compromise. A language model asked about a documented repair doesn't guarantee the same wording twice, and the same model facing a new fault can sound confident without evidence. Neuron7's problem-native AI matches the technique to the problem: deterministic guidance for known issues, and probabilistic methods on Neuron7's Service Decision Graph, the model that connects your products, failure modes, and resolution pathways, for prediction and novel faults.

Here's a simple test you can run in your next demo. Ask the vendor to run the same documented fault twice, then ask for a fault the system has never seen. The first should return the same procedure both times. The second should show its reasoning.

Ask this: Does a known fault return the same deterministic answer every time, and does the system show its probabilistic reasoning on a fault it has never seen?

‍

2. How do you predict failures on disconnected devices?

Predictive maintenance sounds ideal until you count the devices that send no telemetry, meaning no performance data back to the manufacturer. Older units often report nothing, and they're often the hardest to service. A tool that needs live signals ignores them.

Neuron7 predicts from service history instead. Rather than wait for telemetry from the device, it works from the record of how that equipment has behaved and how technicians fixed it. Here's how it works:

1. It reads the history you already have. Product manuals, support tickets, work orders, and resolution records all feed in, not just knowledge articles.
2. It maps that history into one graph. Neuron7 links products, failure modes, resolution pathways, and asset behavior, so it knows when each kind of problem tends to occur and how it was solved.
3. It learns from your technicians. Every step a technician follows or changes feeds back into the graph, so the picture of how your equipment fails gets sharper with each visit.
4. It matches the technique to the question. Predicting what fails next differs from diagnosing today's fault, so Neuron7 applies a prediction technique to the graph instead of asking a language model to guess.

The output is a failure signature: the pattern of symptoms, service events, and technician observations that tends to come before a given failure. When an installed device starts to match one, you see it before the hospital does, connected or not.

Ask this: How do you predict failures on devices that send no telemetry?

‍

3. Does your service guidance leave an FDA audit trail and surface complaints?

Picture your quality lead pulling a complaint file. The question is not what happened. It is what the technician actually did.

Since February 2, 2026, the FDA's Quality Management System Regulation (QMSR) governs device quality under 21 CFR Part 820. It incorporates ISO 13485:2016 by reference, and inspectors now examine quality systems against that framework. The FDA calls proper repair and servicing critical to reliable device performance, so your service records sit in scope.

Most tools treat compliance as paperwork after the visit. Neuron7 builds it into the guidance instead:

• Every recommendation traces to its source data.
• The system captures whether the technician followed a step or departed from it.
• Quality teams get a step-level audit trail for complaint handling and CAPA reviews.
• The same graph exposes recurring failure patterns, so a systemic defect reaches your team early and feeds post-market surveillance and MDR decisions.

Complaint handling is where service and quality collide. A closed work order from three weeks ago can hold a possible patient-safety event described in one line. Field engineers work in the field service system and quality works in the QMS, and nothing carries a case from one to the other, so people comb through closed work orders by hand to find what might be reportable under 21 CFR Part 803.

Neuron7’s Compliant Intake Agent reviews field service activity, flags cases that may need review for FDA reporting, and routes them to the quality team through the QMS. The quality team still decides what’s reportable; the agent helps them find those cases sooner. Neuron7 works alongside your quality management system and supplies the traceable resolution trail it records.

Ask this: Does the audit trail show what the technician did, not just what the system said? And how long does a potentially reportable complaint wait between the field and your quality team?

‍

4. Does every resolution record hold up in an audit?

Some resolution notes pass cursory review and still fail a compliance audit. By the time anyone finds the gap, the technician no longer has the unit in front of them or the visit fresh in memory, and your quality team inherits a record it can’t defend.

Your technician and your quality team won't trust a recommendation they can't check. To earn that trust, the AI has to show the source data behind every recommendation, so anyone can see where an answer came from before they act on it and after the repair. Generic tools often retrieve a probable answer from static content, which leaves the reasoning opaque.

Two parts of how Neuron7 is built make its answers traceable:

• The Service Decision Graph maps products to failure modes, resolution pathways, and asset behavior, and it's built from product manuals, support tickets, and resolutions, not just knowledge base articles. Each recommendation comes from how issues were solved in your own service history, so it carries a path back to the records behind it.
• Problem-native AI uses a different method for prediction, root cause, known resolutions, and novel issues, so a documented fix comes from the approved procedure instead of a guess.

Ask this: Can your AI show me the source behind a resolution and the evidence behind the closed record?

‍

5. Does the AI capture what your best technician knows before they retire?

Every retirement walks a decade of expert knowledge out the door. The people who retire know which fix works on which machine and which step in the manual to skip, and the technicians who replace them troubleshoot those problems from scratch while customers wait longer for fixes a veteran made on the first visit.

Dave Hartley, VP Customer Care at TransLogic, describes where that knowledge lives, in the gap between what the engineer writes in the manual and what the technician does in the field. A static procedure records only what the engineer wrote down, so every fix a technician works out on the job stays in that technician’s head and leaves at retirement.

Capturing that expertise means recording every place a technician departs from the manual, and stateful resolution pathways do that on every visit. When a technician follows a step as written or changes it, the decision feeds back into the graph and sharpens the next recommendation, so your newest hire works from veteran judgment on day one. That learning compounds, which is why Neuron7 customers start on version eight of an architecture built over six years.

Ask this: How does your team capture what technicians learn in the field?

‍

6. When does ROI start, and who does the work?

It's tempting to ask your own team to build an AI tool internally, and plenty of teams try. Connecting a language model to your knowledge base gets you a good-looking demo in a few weeks. But the reality hits you fast. While the demo works on tens of documents, real service content runs to thousands, and that's where generic builds plateau between 50% and 65% accuracy. Add the fact that this isn't your IT team's day job, and the next release keeps slipping behind other priorities. A custom build takes 12 to 18 months to reach production.

Here's a useful rule of thumb: build where it makes sense, and buy the service intelligence layer that has to perform in the field. Neuron7 shows measurable ROI within 90 days and delivers predictions as early as two weeks into deployment, so you're not waiting a year to learn whether it works. If your team already built search or a Copilot, keep it. Neuron7 adds the decision layer on top to ensure 90%+ accuracy, at scale.

The other half of the decision is who does the work. Neuron7 delivers AI-as-a-Service, so forward-deployed engineers, data processing, compute, integrations, and support arrive bundled at a transparent price. The engineers who build your configuration stay to tune it, and pre-built integrations with Salesforce, ServiceNow, Microsoft, and SAP mean you keep the systems you already run. TransLogic and Terumo BCT both run Neuron7 inside Salesforce.

Ask this: When does measurable ROI start, and what would my team maintain after launch?

‍

7. Which customer produced your accuracy and ROI numbers?

Before you believe any vendor's number, learn to read a result. A claim like "double-digit lift in first-time fix" means little until you know who measured it, against what starting point, and over what period. A trustworthy result answers four questions:

• Who? A customer who will speak with you directly about what they saw.
• Compared with what? The baseline the number improved from, such as hours to diagnose before and after.
• Over what period? The first 90 days and the steady state tell different stories.
• Measured how? Resolution accuracy on real service cases differs from a satisfaction survey.

Two Neuron7 customers publish their results, so you can test them against the same four questions:

• TransLogic (Swisslog Healthcare) services computerized tube systems that move materials through hospitals, so downtime hits patient care. TransLogic reached 96% resolution accuracy, cut troubleshooting from 3 hours to 3 seconds (per the customer), saved 960 warranty hours, and saved $90,000 in warranty costs.
• Terumo BCT services blood component and therapeutic apheresis technology and entered new markets with no established knowledge base. In year one, escalations dropped 20%, average part cost per escalated work order fell 24%, and the deployment returned about 3x ROI, roughly $500,000 in first-year savings.

Ask this: Which customers achieved results, and how do you establish a baseline?

‍

Before your next vendor meeting

1. Send the seven questions in advance. A vendor that can't answer in writing won't answer better live.
2. Ask for two references in your device category, then call them. Customers with real results take the call.
3. Hand the audit-trail and complaint questions to your quality lead. They know what an inspector asks.
4. Put the ROI window in the proposal. A defined date beats a promise.

‍

See it how it works

Your install base has its own failure patterns, and your auditors have their own questions. Talk to the team about your medical devices and your audit requirements. Measurable ROI starts within 90 days.