Medical device field service records for failure prediction and service AI

Why public device data cannot train failure prediction

Public data covers reported events, not the fleet denominator, so it cannot estimate failure rates or time-to-failure. FDA's MDR data files hold reports of deaths, serious injuries and malfunctions, split into device, patient, narrative text and problem-code files joined by an MDR report key [1]. They omit facility location and overlap with legacy files [2], and they say nothing about the thousands of uneventful service calls, PM visits and part swaps that a failure model needs as context.

Generic benchmarks do not fill the gap either. The AI4I 2020 dataset widely used for predictive maintenance is synthetic, with roughly 10,000 rows and five labeled failure modes [7]. A CT tube, MRI cold head or infusion pump fleet fails in ways that only real service histories reveal. See labeled equipment failure data for predictive maintenance for the cross-industry labeling problem.

What a service record set should contain

The minimum useful unit is one work order joined to the asset, its logs and its parts, with timestamps that allow event-window construction. Ask suppliers which system holds each element: OEM field service platforms, a hospital CMMS (healthcare technology management systems), remote-monitoring log collectors, and ERP parts records often live apart.

• Asset master: manufacturer, model, software version, install date, contract type (OEM full service, ISO, in-house), UDI-DI where recorded.
• Work orders: open and close timestamps, reported symptom, problem code, technician narrative, root cause, corrective action, downtime hours, first-time-fix flag.
• Machine logs: error codes, subsystem events, sensor readings (helium level, tube current, temperatures) for a window before each call.
• Parts: part numbers, quantities, serials removed and installed, return-material findings.
• PM and safety tests: scheduled versus completed checklists, electrical safety results, calibration values.

Reliability practitioners can map failure modes and causes to an ISO 14224-style taxonomy, which was written for petroleum equipment but gives a disciplined structure for equipment, failure mode and maintenance action fields [6]. Where service events touch adverse-event coding, IMDRF Annex A device problem codes give a shared vocabulary [3].

Illustrative work order record

A joined record should let a model see symptom, logs, action and outcome together.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "work_order_id": "WO-hashed-7f3a",
  "asset": {"modality": "CT", "model_family": "64-slice", "sw_version": "VB20", "contract": "ISO"},
  "opened_at": "2025-03-04T07:12:00Z",
  "closed_at": "2025-03-04T15:40:00Z",
  "reported_symptom": "Scan aborted, tube arc errors during morning warm-up",
  "error_log_window": [{"code": "ARC_DETECT", "count_24h": 17}, {"code": "HV_FAULT", "count_24h": 3}],
  "technician_note": "Arc count elevated. Tube seasoning failed. Replaced X-ray tube.",
  "parts": [{"part_class": "x_ray_tube", "qty": 1, "removed_serial": "hashed"}],
  "root_cause": "tube end of life",
  "possible_complaint_flag": false,
  "phi_scrub": {"method": "DICOM header profile + free-text NER", "sample_checked": true}
}

Complaint linkage and the servicing boundary

Service records are quality records for manufacturers, so buyers should treat their regulatory context as both a labeling resource and a diligence item. As of October 2026, FDA's device quality rules under 21 CFR Part 820 align with ISO 13485:2016, and manufacturers are expected to evaluate service reports that may describe a device failure as potential complaints. Ask whether each work order was screened for a possible complaint and whether the supplier can join it to the complaint file and any MDR record; that flag is a valuable label and a sign the record set is complete. Complaint and MDR decisions are covered in medical device complaint files and MDR reportability decisions.

FDA guidance finalized in 2024 separates servicing, which returns a device to OEM specifications, from remanufacturing, which significantly changes performance, safety specifications or intended use and carries premarket and postmarket duties. Records from third-party servicers can include work near that line, such as non-OEM parts, refurbished assemblies or software changes. Tag each record with its activity type before training a model that recommends repairs, and have counsel confirm the current guidance text.

Common failure modes in service data

• Survivorship gaps: only failed assets appear, so hazard rates are inflated.
• Code drift: problem-code lists change across software releases or CMMS migrations, splitting one failure into several labels.
• Narrative copy-paste: technicians reuse closure notes, which inflates summarization scores.
• Clock skew: machine logs in local time and work orders in UTC break event windows.

PHI in logs, worklists and images

Machine logs are not automatically free of patient data, so scrubbing must cover structured fields, free text and embedded files. Imaging service bundles often contain DICOM files whose headers carry patient name, ID and study dates; DICOM's attribute confidentiality profiles, including the Basic Application Level Confidentiality Profile, define how to de-identify them [5]. Technician notes may quote a patient's name or a room and date from the worklist.

When records come from a covered entity or its business associate, the HIPAA standard applies: Safe Harbor removes 18 identifier types, and Expert Determination relies on a qualified expert's risk assessment [4]. Device serial numbers and UDIs are themselves on the Safe Harbor identifier list when linked to a patient, so decide early whether you need serial-level joins or hashed asset keys. Ask for the method used and a reviewed sample, not a promise of zero residual risk.

Who can license the records

Rights are split, so confirm who controls each record set before scoping. An OEM holds its field service and remote-monitoring data but may be bound by service contract terms with hospitals; a hospital biomedical department holds its CMMS but may hold OEM logs only under a service agreement; an ISO holds records it created for client hospitals. The authorization issues are covered in client data held by service providers and chain of title for AI training data.

Buyer checklist before requesting samples

• State the target: failure prediction (needs logs plus outcome labels), remote triage (symptom text plus first-call resolution), or summarization (narratives plus structured closure codes).
• Specify modalities, model families, years and minimum assets per model.
• Require a fleet denominator: all assets and all work orders, not only failures.
• Ask how problem codes changed over time and whether a mapping table exists.
• Request the de-identification method, complaint-flag logic and data owner for each source system.

For adjacent record types, compare MES production records and downtime data and aircraft maintenance records, and see the industry-specific operational data hub. SourceX's maintenance work order datasets page, maintenance logs page and healthcare buyers page describe related categories. Teams ready to scope a request can describe the records they need.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Request medical device service records

SourceX sources operational datasets, including engineering records and support histories, from US companies on request; it holds no stock, and a request does not guarantee a match. Every dataset is rights-reviewed, personal details are removed or replaced with the method recorded, health records require HIPAA de-identification, and every release is approved by the supplying company. Describe the service data you need.