Medical Device Service

Covers OEM installation and commissioning of a regulated medical device at a customer site, executed in IFS Cloud as a Work Order and Work Task chain against a newly registered Service Object. Installation Qualification and Operational Qualification are driven as work task checklists with test point and parameter measurement capture, and the signed qualification package is retained as Documents against the object. The process closes with QA release for clinical use, warranty activation and instantiation of the recurring service program.

Governs the formal handover gate at the end of a medical device install: acceptance tests executed against the Service Object test points, deviations captured as punch-list Work Tasks, and a signed acceptance certificate attached to the object as a Document. Sign-off is the event that sets the object In Operation, starts the customer warranty validity period and releases the commissioning Work Order postings to a Customer Order for invoicing. Refused acceptance is a terminal outcome that keeps the device out of clinical use until the punch list is cleared and the gate is re-run.

Controls the release and field deployment of medical device software and firmware updates, including cybersecurity patches, across an installed base tracked in IFS Cloud. Each approved update becomes a planned campaign that generates Work Orders per affected Serial Object, records the pre and post update version, and captures verification evidence. Regression to the prior version is retained as an explicit rollback path.

Turns accumulated IFS Cloud service data - work order failure codes, fault reports, complaint cases and returned-part findings - into a statistically defensible trend signal that either triggers a CAPA or produces a documented reason not to. IFS Cloud is the data source and the place corrective actions are implemented; the CAPA record itself is a quality-system artefact with no standard IFS Cloud object. Effectiveness is verified against the same trend metric that raised the signal.

Plans a field safety corrective action from the moment a safety signal is confirmed to the point an approved FSCA plan and field safety notice are released for execution. In IFS Cloud the process is anchored on the installed base: the affected population is reconstructed from the Part Serial Catalog, lot/batch records and Serial Object registry, and the consignee list is derived from Customer Order and part serial history. The regulatory artefacts themselves (FSCA plan, health hazard evaluation, field safety notice) have no standard IFS Cloud object and are normally held as Documents or in the eQMS.

Executes an approved recall or field campaign across the affected installed base and proves it worked. In IFS Cloud each affected Serial Object gets a Work Order and dispatched Work Tasks with the corrective kit reserved from inventory, while consignee notification, response and effectiveness-check outcomes are tracked to the level set in the recall strategy. Effectiveness-check records and recall status reports have no standard IFS Cloud object and are held as Documents or in the eQMS against the campaign.

Controls the lifecycle of the service procedures, work instructions and reference measurements that engineers use on marketed devices, so the revision in an engineer's hand is always the approved one. IFS Cloud Document Management holds the controlled revision and its attachment to work task templates and objects; approval routing, obsolete-copy withdrawal and training assignment are enforced as part of release. The driver is usually a CAPA action, a design change or a regulatory update.

Maintains the medical device installed base in IFS Cloud so every device at a customer site is a Service Object carrying its Model, part, serial number and UDI identification. The FDA Device Identifier is held against the model or part record while the object serial number carries the Production Identifier, giving a traceable link from the object structure back to the labeler GUDID entry. Object structures, connected parties and move history keep location, ownership and configuration current for entitlement, recall and field safety corrective action purposes.

Controls the tools, gauges and test instruments that technicians use on medical devices, so that no measurement is ever taken with an out-of-calibration instrument. Each instrument is held in IFS Cloud as its own Serial Object with a calibration maintenance plan, a due date and a traceability record. Instruments that fall due are blocked from issue, and any measurement taken with a later-failed instrument triggers a recall of affected results.

Plans and executes manufacturer-recommended preventive maintenance (PM) on medical devices using IFS Cloud maintenance plans that generate dated PM work orders against each Serial or Functional Object. Intervals, task content and acceptance criteria are driven by the OEM service manual and by the facility risk-based maintenance strategy. Completion evidence is captured on the work task so every serviced device carries a defensible service record.

Calibrates and performance-verifies medical devices against documented tolerance limits and issues a traceable calibration certificate for each event. IFS Cloud carries the calibration interval as a maintenance plan on the device object and captures as-found and as-left readings as measurements on the work task. The certificate itself is a regulatory artefact with no standard IFS Cloud object and is normally held as an attached Document.

Performs electrical safety testing of medical electrical equipment before it is put into service, during maintenance and inspection, and after repair, recording protective earth resistance, insulation resistance and leakage current readings against the pass/fail limits in IEC 62353. IFS Cloud carries the test as a task on the PM or repair Work Order and captures each reading as a measurement. A failed test drives the device out of service until it is corrected and retested.

Runs depot repair and refurbishment while keeping the work on the servicing side of the FDA remanufacturing boundary. IFS Cloud carries the flow as RMA receipt into the depot, a repair Work Order with a linked repair Shop Order that issues and receives back the same serial, traceable part consumption, QA release via the operational condition change, and MRO shipment back to the customer. The scoping decision - whether the intended activity significantly changes the finished device performance or safety specifications or intended use - is the control point, and it has no standard IFS Cloud object.

Establishes IFS Cloud as the electronic system of record for medical device servicing activities, so that service records held electronically in place of paper satisfy 21 CFR Part 11 alongside the underlying Part 820 predicate rule. The design decides which records are Part 11 records, controls system access and electronic signature use, and preserves a time-stamped audit trail. Part 11 artefacts such as the audit trail and the validation record have no standard IFS Cloud object and are handled as system capability and controlled documents.

Takes a triaged complaint plus its service and diagnostic evidence and reaches a documented, clock-aware reportability decision for FDA MDR and EU MDR vigilance. IFS Cloud supplies the operational evidence - Case, Fault Report, service report, UDI and serial identification, awareness date - while the decision, the eMDR submission and the not-reportable rationale live in the regulatory system. The process exists to make the awareness date defensible and the decision traceable to a specific device and event.

Closes a field action and discharges the reporting obligations that attach to it. IFS Cloud supplies the reconciliation evidence - units corrected, removed, scrapped and unaccounted, drawn from Work Order completion and part serial history - which feeds the 21 CFR Part 806 correction/removal report, the EU MDR competent-authority notification and the recall termination request. The 806 report, the non-reportable record and the closure file itself have no standard IFS Cloud object and sit in the eQMS or Document Management.

Establishes end-to-end traceability for service parts and devices so an affected population can always be reconstructed. IFS Cloud carries this through Part Catalog tracking flags, the Part Serial Catalog and Part Lot Batch, as-built structures and part serial history, capturing the UDI device identifier and production identifiers at receipt and preserving them through consumption on Work Orders and Shop Orders. The GUDID submission itself is external, but the identifiers and the lot-to-consignee trace are IFS data.

Controls shelf-life-limited service parts - reagents, sterile accessories, batteries, adhesives and seals - so nothing expired reaches a patient-facing device. In IFS Cloud the expiration date is derived from the manufactured date and the shelf life defined on the part, held on Part Lot Batch or Part Serial, and enforced at reservation: automatic reservation requires the part to be current and can be prioritised by Earliest Expiration Date, while manual reservation can deliberately override and reserve expired stock.

Manages the loaner pool that keeps a clinical customer running while their own device is down or under field action. In IFS Cloud the loaner is a serial tracked part: allocation reserves the specific serial, shipment moves its current position to Issued, and return runs through a Return Material Authorization where it is either received back to stock or scrapped against a scrapping cause. Operational condition and operational status carry the fit-for-use decision that governs reissue.

Ensures that only technicians holding current, model-specific training and certification are dispatched to service a medical device, and that the qualification evidence is retrievable per service event. Competencies and qualifications are held against the Employee record in IFS Cloud and matched to work task requirements during scheduling. Expiring certifications withdraw eligibility rather than merely raising a warning.