Industry solution

Medical Devices & Diagnostics

From complaint to corrected device, every record linked by serial number

Design records, device history, complaints, field actions, service and user training, designed to link through each serial number.

Products
8
Challenges
6
Concepts
15
Talk to us about Medical DevicesAsk a question
Field service engineer testing an infusion pump at a service depot bench, with a blood gas analyzer waiting beside it.
ManufacturedOps(opens ManufacturedOps in a new tab)AssetHandler(opens AssetHandler in a new tab)LabsOfScience(opens LabsOfScience in a new tab)CrewFoundry(opens CrewFoundry in a new tab)BuildMyIQ(opens BuildMyIQ in a new tab)Botlit(opens Botlit in a new tab)FluidGrids(opens FluidGrids in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

Why post-market evidence is hard for device makers

One complaint about one serial number reaches the design file, the device history record, the installed base, the service team and customer training, and the evidence for each sits in a different system.

Device and diagnostics manufacturers are judged on evidence that runs from the first design input to the last unit in the field. Design controls expect every requirement and risk control to trace to a verification result. Production expects a device history record for every lot or serial. After shipment, complaints must be captured, evaluated and trended, and a field action has to reach every affected unit wherever it sits today.

In most companies these records live in separate places: a document system for the design history file, spreadsheets for the trace matrix, paper travelers and test-station exports for device history, a shared inbox for complaints, a service tool for the installed base, and sign-in sheets for customer training. Each works on its own. The seams between them are where a service note never becomes a complaint, where a field action stalls on a distributor's stock, and where an audit question takes a week.

The pressure does not let up: new product introductions, component changes, regulators in several markets, and service teams stretched across wide territories. What helps is records that link through the serial number, automation for the routine hand-offs, and clear ownership of each quality decision.

Who this is for

  • VP of Quality and Regulatory Affairs

    Complaints, CAPAs and field actions closed on evidence, and records that answer an auditor's question without a week of assembly.

  • Complaint Handling and Post-Market Surveillance Lead

    Every complaint captured once from any channel, linked to the unit's history, and trends spotted before they become field actions.

  • Design Assurance or Verification Lead

    Knowing which requirements and risk controls a design change touches, and which verification tests must be run again.

  • Production Quality Engineer

    A complete device history record for every serial, with calibrated test equipment and qualified operators behind each result, before release.

  • Field Service Director

    Engineers qualified on the right model and procedure revision, the installed base located, and each correction recorded against its serial.

  • Clinical Education Manager

    Proof of which operators at each customer site were trained on the current instructions for use, and which sites are still waiting.

A day in the life

The story behind the solution

From Monday's complaint to Friday's training sessions

Ingrid Halvorsen runs quality and regulatory affairs at Tessaly Medical. Its AM-300 volumetric infusion pump and BX-20 blood gas analyzer are installed in hospitals and clinics across three service regions, looked after by field service engineers and clinical application specialists. One complaint on a Monday morning travels through her whole operation by Friday. This is that week.

  1. Monday, 08:10

    Three reports of a silent alarm

    Hamid Karimi, the complaint handling specialist, starts the week with the same failure reported in three places. A hospital's biomedical engineering lead has emailed that two AM-300 pumps did not raise a downstream occlusion alarm during pre-use checks, with no patient connected. A distributor has typed a similar report about another pump into the customer portal chat. And a service engineer's work order from the previous Friday reads 'occlusion alarm late at test pressure, sensor recalibrated', a note nobody flagged as a complaint. Beatriz Nunes in regulatory affairs needs the facts to make reporting decisions, and nobody yet knows what the units have in common.

    How this is solved: Complaints scattered across inboxes, chats and service notes

  2. Tuesday, 14:00

    120 pumps due to ship, checked serial by serial

    Diego Salcedo, the production quality engineer, has 120 AM-300 pumps waiting for release to a distributor on Wednesday. Each serial's device history record must match the device master record: traveler steps signed, firmware 4.2 loaded, final functional tests passed on a calibrated fixture by a signed-off operator, unique device identifier (UDI) labels printed, applied and scanned, the accessory kit complete, and any nonconformance closed. The evidence is scanned travelers, test-station exports, a label-room log, a calibration spreadsheet and a training binder. Since Monday he must also make sure none of the 120 contains pressure sensor lot PS-2291.

    How this is solved: Device history records checked serial by serial before release

  3. Wednesday, 10:30

    A firmware fix and a replacement sensor

    Engineering proposes firmware 4.3, which tightens occlusion detection, and a replacement pressure sensor from an alternative supplier. Lin Zhao, who leads design verification, must say which design inputs, risk controls and verification tests the change touches before the change board meets on Friday. The trace matrix is a spreadsheet of more than nine hundred rows last reconciled at the previous design review, the verification reports are PDFs on a shared drive, and nobody is sure which version of the occlusion test protocol produced the last passing result.

    How this is solved: Design changes that outrun the verification record

  4. Thursday, 09:00

    1,140 pumps at 64 customer sites

    The field action review board decides on a field correction: every AM-300 built with sensor lot PS-2291 gets a replacement sensor from a released lot, with firmware 4.3 to follow once its verification is complete. Ingrid's team has the shipping records, but hospitals move pumps between facilities, a distributor holds stock, and some units are out as loaners. Field safety notices will go out by email and courier, signed acknowledgments will come back as scans, and the effectiveness check will live in a spreadsheet updated on Fridays unless something changes.

    How this is solved: Field actions that stall on where each device is

  5. Thursday, 15:00

    Who is qualified on revision C

    Marcus Oyelaran, the field service director, has the correction visits to plan on top of routine preventive maintenance due on BX-20 analyzers under service contracts. The sensor replacement follows revision C of the service procedure and needs a calibrated pressure test kit. Which engineers have completed revision C training is in the training coordinator's spreadsheet; the test kits' calibration dates are in another. That evening an engineer at a customer site phones Marcus to ask whether a step changed from revision B.

    How this is solved: Service visits by engineers current on the model and procedure

  6. Friday, 11:00

    Refresher sessions and two new analyzers

    The field safety notice adds a step to the AM-300 pre-use check in the instructions for use, so Sunita Rao's clinical application specialists must run refresher in-service sessions at every affected site. Two clinics are also receiving new BX-20 analyzers, and neither handover can happen until their operators are trained. Attendance is recorded on paper sign-in sheets photographed after each session, customers are asking for proof of who was trained, and Sunita cannot say which sites still have operators waiting.

    How this is solved: Customer training records that live on sign-in sheets

None of this is unusual. It is the ordinary post-market work of a device maker, made hard because the evidence is spread across systems that do not share the serial number. The rest of this page shows how Burdenoff products are designed to work together so that each question Ingrid faced this week has one traceable answer.

Challenges and how they are solved

6 problems, several products, one connected answer

Each challenge shows the problem as it happens, how the products are designed to hand work to each other, and the concepts that illustrate it. Share any challenge on its own.

Answers are in plain business terms. Choose Technical, or open any technical detail, to see how it works under the hood.

Challenge 1 of 6

Complaints scattered across inboxes, chats and service notes

Botlit(opens Botlit in a new tab)FluidGrids(opens FluidGrids in a new tab)ManufacturedOps(opens ManufacturedOps in a new tab)LabsOfScience(opens LabsOfScience in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

A device complaint rarely arrives neatly. The same failure shows up as an email from a hospital's biomedical engineering lead, a message typed into the customer portal chat by a distributor, and a line in a service engineer's work order saying the alarm was late and the sensor was recalibrated. Each lands in a different place, and the service note may never be recognized as a complaint at all. Before anyone can evaluate the event, someone has to find the unit's build records, check for similar reports and request the returned device, while regulatory affairs waits for enough facts to make a reporting decision within the company's timelines.

What it costs

Complaints are logged late or not at all, related reports go unlinked, and reporting decisions are made on partial facts.

How the products work together

Botlit takes problem reports in the customer portal and is set up to pass questions about patient care to a person. FluidGrids also catches emailed reports and service notes an engineer flags. Each report gets its own file in ManufacturedOps, linked to similar ones, with the unit's build history attached. Named people record reporting and corrective-action decisions, and BigConsole flags a problem reported more often than a set limit.

How it works — technical detail

Technical detail

A Botlit agent on the customer portal is designed to collect the model, serial number and event as reported, decline clinical questions and hand them to a person, and start a FluidGrids intake workflow. FluidGrids can also watch a Gmail complaints inbox and, every 15 minutes, check AssetHandler for work orders an engineer flagged as a possible complaint. It is designed to open a complaint file in ManufacturedOps for each report and link it to open files with the same model and failure mode; the complaint unit confirms duplicates. Each file is designed to pull the serial's device history from ManufacturedOps genealogy, list similar complaints and link the returned-unit analysis run in LabsOfScience. Named people record whether the complaint is confirmed, the reporting decision and any CAPA. FluidGrids can feed complaint counts into a BigConsole datasink, where a threshold alert is designed to flag a failure mode whose monthly count crosses the limit the quality team sets.

The outcome it is designed for

Every report is designed to start its own complaint file, whatever the channel, linked to related reports and with the unit's history attached before the evaluation begins.

The concepts behind it

ManufacturedOps

Device Complaint File and History Trace

Holds one file per report with its intake, the serial's device history, related and similar complaints, the returned-unit analysis and the named decisions on reporting and CAPA.

Works with Botlit, LabsOfScience, AssetHandler

Concept pagefor Device Complaint File and History Trace on the ManufacturedOps website (opens in a new tab)

Challenge 2 of 6

Device history records checked serial by serial before release

ManufacturedOps(opens ManufacturedOps in a new tab)AssetHandler(opens AssetHandler in a new tab)CrewFoundry(opens CrewFoundry in a new tab)

The problem

Before a lot of finished devices ships, quality must confirm each serial's device history record against the device master record: the routing and revisions it was built to, the firmware version loaded, final functional tests within limits, the test fixture in calibration, the operator qualified on the station, unique device identifier (UDI) labels printed, applied and scanned, and the right accessories in the kit. In many plants the evidence sits on scanned travelers, test-station exports, a label-room log, a calibration spreadsheet and a training binder, compared by eye, serial by serial, while a shipment waits on the dock.

What it costs

Release decisions wait on manual assembly, gaps surface late, and a unit with the wrong firmware or an unreconciled label can ship.

How the products work together

ManufacturedOps is designed to check each unit's build record against the approved design: the right parts and revision, the right software loaded, every label printed and applied, and the right accessories in the box. It asks AssetHandler whether the test equipment was calibrated and CrewFoundry whether the operator was signed off, and lists every gap before a named quality engineer releases or holds.

How it works — technical detail

Technical detail

ManufacturedOps records production orders, operations, inspections, component lots and nonconformances as the work happens, and is designed to check each serial's device history record against the device master record: routing and revision, the firmware version loaded, UDI labels printed against labels applied and scanned, and the accessories in the kit. Each final functional test records the operator and the test fixture's AssetHandler asset tag. At release review, ManufacturedOps is designed to ask AssetHandler whether that fixture was in calibration on the test date, and to check the operator's station sign-off in CrewFoundry for the same date; any gap becomes a blocking item on the checklist, as do open nonconformances and serials held under a suspect-lot trace (see field actions). A named quality engineer releases or holds with the evidence in view.

The outcome it is designed for

Device history review is designed to start from a list of what is still open for each serial, from firmware and labels to test evidence, before units reach the dock.

The concepts behind it

Challenge 3 of 6

Design changes that outrun the verification record

LabsOfScience(opens LabsOfScience in a new tab)ManufacturedOps(opens ManufacturedOps in a new tab)CrewFoundry(opens CrewFoundry in a new tab)

The problem

A design change looks small on the change request and large in the design history file. A firmware update that tightens occlusion detection, or a replacement sensor from an alternative supplier, touches design inputs, risk controls, verification tests and the production line's instructions. The trace matrix is often a spreadsheet reconciled only at design reviews, verification reports are PDFs on a shared drive, and it is hard to prove which protocol version and which test equipment produced the last passing result. Engineers rebuild the impact assessment from memory before the change board meets, and production learns about new test limits from an email.

What it costs

Tests that should be repeated can be missed, others are repeated without need, and the design history file falls behind the device actually being built.

How the products work together

LabsOfScience keeps every verification test with the exact method version and the signed result, and is designed to show which requirements and safety controls a proposed change affects and which tests must be run again. When the new results are signed, ManufacturedOps gives the line the updated instruction, and CrewFoundry assigns the matching training to operators.

How it works — technical detail

Technical detail

In LabsOfScience each verification test is a published protocol version, and each execution is a run with signed and witnessed notebook entries and an immutable dataset version. A trace matrix is designed to link every design input and risk control to the protocol and the latest signed run that verifies it. When a change such as firmware 4.3 is proposed, the rows it touches are flagged for re-verification, and inputs with no linked test show as gaps. Once the re-runs pass and are signed, the change is designed to reach ManufacturedOps as a new version of the test-station work instruction and inspection plan, effective for production orders from a set date. CrewFoundry can then assign read-and-understood training on the revised instruction to the operators who run that station.

The outcome it is designed for

A design change is designed to reach the change board with its re-verification list, and the line as a new instruction version with training assigned.

The concepts behind it

LabsOfScience

Device Design Verification Trace Matrix

Is designed to link each design input and risk control to its verification protocol version and latest signed run, and to flag the rows a proposed change requires to be verified again.

Works with AssetHandler, ManufacturedOps

Concept pagefor Device Design Verification Trace Matrix on the LabsOfScience website (opens in a new tab)

Challenge 4 of 6

Field actions that stall on where each device is

ManufacturedOps(opens ManufacturedOps in a new tab)AssetHandler(opens AssetHandler in a new tab)FluidGrids(opens FluidGrids in a new tab)CrewFoundry(opens CrewFoundry in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

Once a field action is decided, a component lot has to become a list of serial numbers, and each serial has to become a customer site, a named contact and a current location. Shipping records show where units went, not where they are now: hospitals move devices between facilities, distributors hold stock, and loaners come and go. Field safety notices go out by email and courier, signed acknowledgments come back as scans, and corrections are written up in service reports. The effectiveness check is a spreadsheet reconciled by hand each week, and the units nobody can find are the ones that matter most.

What it costs

Notices reach the wrong person, corrections lag, and status reports for management and regulators take days to assemble and are out of date when sent.

How the products work together

ManufacturedOps lists every finished unit that contains the suspect part. AssetHandler matches each one to the customer site where it is installed and tracks it from notice sent to acknowledged, corrected or not found. FluidGrids sends the safety notices, chases replies, escalates silence and keeps BigConsole's progress board current, and CrewFoundry helps find a qualified engineer for each correction visit.

How it works — technical detail

Technical detail

ManufacturedOps genealogy is designed to trace the suspect lot forward to every finished serial that contains it, giving the field action its scope. FluidGrids can pass that serial list to AssetHandler, where each serial is designed to be matched to its installed-base record: customer account, site, distributor, service contract and last visit. AssetHandler's field action tracker shows every account's units from notice sent to acknowledged, corrected or not located. A FluidGrids workflow can send the field safety notice to each site's named contact, wait for the acknowledgment, send reminders and escalate to the account's service manager, recording every run, and push the tracker's site statuses into a BigConsole datasink each hour. AssetHandler raises a correction work order for each site, and each work order is designed to go to CrewFoundry for a qualified engineer; each corrected serial is recorded against its installed-base record.

The outcome it is designed for

The field action is designed to be tracked serial by serial and site by site, with the units not yet located visible from the first day.

The concepts behind it

AssetHandler

Device Field Action Installed-Base Tracker

Shows every affected serial by customer account and distributor, from notice sent to acknowledgment returned, corrected or not located, with the effectiveness check in view.

Works with ManufacturedOps, FluidGrids, CrewFoundry

Concept pagefor Device Field Action Installed-Base Tracker on the AssetHandler website (opens in a new tab)

Challenge 5 of 6

Service visits by engineers current on the model and procedure

AssetHandler(opens AssetHandler in a new tab)CrewFoundry(opens CrewFoundry in a new tab)Botlit(opens Botlit in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

A correction visit is only as good as the engineer who performs it. The sensor replacement follows a specific revision of the service procedure and needs a calibrated pressure test kit, while routine preventive maintenance on analyzers under service contracts falls due in the same weeks. Who has completed training on the new revision sits in a coordinator's spreadsheet, test-kit calibration in another, and territory schedules in a third. At a customer site in the evening, an engineer who wants to confirm a step calls a colleague. Anything unexpected the engineer notices goes into a free-text service report the complaint team may never read.

What it costs

Visits can be booked with engineers or test kits that are not current, first-time fixes suffer, and field observations that should become complaints are lost.

How the products work together

AssetHandler holds each service and correction visit against the installed unit. CrewFoundry is designed to show which engineers are trained on that model and procedure version and have a calibrated test kit. On site, Botlit points the engineer to the exact step in the approved manual. At close-out the engineer records parts and readings against the unit, and anything unexpected goes to the complaint team.

How it works — technical detail

Technical detail

AssetHandler holds each correction and preventive maintenance visit as a work order against the installed serial, with the checklist from the current service procedure. CrewFoundry's readiness matrix is designed to show which engineers have read and understood revision C for that model, whose sign-offs are expiring, and whether each engineer's assigned test kit is in calibration in AssetHandler; the planner picks a ready engineer, and CrewFoundry is designed to write the assignment back onto the AssetHandler work order. At the site, a Botlit agent grounded in the controlled service manual library is designed to point the engineer to the exact step in the controlled revision C procedure, which the engineer follows, and to say plainly when it has no answer. On close-out, the engineer records parts used and as-found and as-left occlusion readings against the serial in AssetHandler, and anything unexpected is flagged for FluidGrids to pick up as described under complaint intake.

The outcome it is designed for

Each visit is designed to go to a qualified engineer with a calibrated kit, and observations from the field reach the complaint team instead of a report archive.

The concepts behind it

CrewFoundry

Device Service Procedure Revision Readiness

Shows which engineers have read and understood the current service procedure revision for each model, whose sign-offs expire soon and whether each engineer's test kit is in calibration.

Works with AssetHandler, BuildMyIQ

Concept pagefor Device Service Procedure Revision Readiness on the CrewFoundry website (opens in a new tab)

Challenge 6 of 6

Customer training records that live on sign-in sheets

BuildMyIQ(opens BuildMyIQ in a new tab)CrewFoundry(opens CrewFoundry in a new tab)AssetHandler(opens AssetHandler in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

When the instructions for use change, or a new analyzer is installed, the people who operate the device at the customer site need training on its operation, and the manufacturer needs a record of who received it. Clinical application specialists run in-service sessions on wards and in labs, collect paper sign-in sheets and photograph them for a regional spreadsheet. Customers ask for proof of who was trained, the specialists themselves must be current on the updated content, and nobody can say which sites still have operators waiting. During sessions, specialists are asked clinical questions that belong with the customer's own clinical leaders.

What it costs

Training gaps after a field notice or a new installation stay invisible, customers cannot get proof of training, and handovers wait on paperwork.

How the products work together

BuildMyIQ is designed to track operator training account by account, from booked sessions to certificates, and to hold a new installation's handover until its operators are trained. FluidGrids turns each new installation or safety notice recorded in AssetHandler into a training need, and CrewFoundry shows which specialists can teach it. Sessions are designed to cover device operation only.

How it works — technical detail

Technical detail

BuildMyIQ is designed to organize operator training by customer account and installed device model: short courses built from the instructions for use and the field notice update, facilitator-led cohorts with seats and dates, a brief knowledge check and a certificate for each operator, with attendance and certificate expiry designed in. A nightly FluidGrids workflow can turn new AssetHandler installations, and each account's acknowledged field notice, into training requirements in BuildMyIQ, so a new analyzer's handover is held until its operators are trained. CrewFoundry shows which clinical application specialists are current on the updated content and can facilitate the session. Content is designed to cover device operation only, as written in the instructions for use, with clinical questions referred to the customer's clinical leaders.

The outcome it is designed for

Every affected account is designed to show how many operators are trained on the current instructions, and a new installation's handover is designed to wait until its operators are.

The concepts behind it

BuildMyIQ

Device User In-Service Training Tracker

Shows one field notice's training across customer accounts, from notice acknowledged to operators trained on the current instructions, and holds a new installation's handover until its operators are trained.

Works with AssetHandler, CrewFoundry

Concept pagefor Device User In-Service Training Tracker on the BuildMyIQ website (opens in a new tab)

How it fits together

How one complaint reaches a corrected pump and a trained operator

Follow one thread through the week: a report of a silent occlusion alarm becomes a complaint file, a scoped field action, qualified service visits and refresher training, with a person deciding at each step. Each hand-off shows how the products are designed to work together.

  1. To FluidGrids: The report, with model and serial number

  2. To ManufacturedOps: Three linked complaint files

  3. To AssetHandler: The list of 1,140 affected pumps

  4. To CrewFoundry: Correction jobs that need a qualified engineer

  5. To BuildMyIQ: Which specialist runs each site's refresher session

  6. To BigConsole: Training and correction progress by site, passed on by FluidGrids

  7. To Botlit: Live figures Botlit can answer questions from

Step 1 of 8: Capture

How each hand-off works — technical detail

Technical detail

  1. 1. Botlit — Capture: Collects the model, serial number and event details from a distributor's portal message, is designed to pass clinical questions to a person, and routes it as a possible complaint.Hands to FluidGrids: Structured complaint details that start a FluidGrids intake workflow
  2. 2. FluidGrids — Route: Opens a complaint file in ManufacturedOps for each of the portal report, the emailed report and the flagged service work order, and links them as related.Hands to ManufacturedOps: Three linked complaint files
  3. 3. ManufacturedOps — Investigate and scope: Traces each serial's device history, links similar complaints and the LabsOfScience returned-unit analysis; after the review board decides, lists every serial with lot PS-2291.Hands to AssetHandler: The field action's serial list: 1,140 AM-300 pumps
  4. 4. AssetHandler — Locate: Matches each serial to its installed-base account, site and contact, tracks notices and acknowledgments, and raises a correction work order for each site.Hands to CrewFoundry: Correction work orders that need a revision C qualified engineer
  5. 5. CrewFoundry — Assign: Shows which engineers are current on AM-300 revision C with a calibrated test kit for each correction work order, and which specialists can run each refresher session.Hands to BuildMyIQ: Specialist assignments for the refresher in-service sessions
  6. 6. BuildMyIQ — Train: Runs the refresher sessions on the updated pre-use check, is designed to record attendance, issues certificates and flags accounts with operators still waiting.Hands to BigConsole: Training completion by site, pushed with the field action's site statuses into a BigConsole datasink by a scheduled FluidGrids workflow
  7. 7. BigConsole — Watch: Shows field action progress on one console: accounts notified and acknowledged, units corrected, units not located and operators trained, with drill-down by region.Hands to Botlit: Live console figures an agent can query and cite
  8. 8. Botlit — Answer: Is designed to answer 'which sites still have uncorrected pumps?' from the console, citing it, ahead of the weekly field action review.

Products in this solution

What each product brings

  • ManufacturedOps

    Device history, corrective actions and complaint files

    It records how every unit was built, tested and inspected, and which parts went into it. It is designed to hold each complaint with the unit's build history, and to list every unit a suspect part reached.

    Technical detail

    Technical detail

    Records production orders, operations, inspections, component lots, nonconformances and corrective and preventive actions (CAPA) as the work happens, with forward and backward genealogy, and is designed to add complaint files built on its nonconformance, CAPA and genealogy records.

    Visit ManufacturedOpsAll concepts

  • AssetHandler

    Installed base, field actions, calibration and service

    It keeps track of test equipment calibration and every service visit. It is designed to know where each installed device sits at each customer, so a safety notice and its correction can be tracked unit by unit.

    Technical detail

    Technical detail

    Keeps assets with location, custody, preventive maintenance and work orders, and is designed to keep a calibration register for test equipment and to hold the installed base as assets at customer-site locations, so a field action can be tracked serial by serial.

    Visit AssetHandlerAll concepts

  • LabsOfScience

    Design verification and returned-unit analysis

    It keeps each test method with every version preserved, and each test result signed and witnessed. It is designed to link each requirement and safety control to the tests that prove it, and to show which tests a design change means running again.

    Technical detail

    Technical detail

    Holds verification tests as published protocol versions and runs with signed and witnessed notebook entries and immutable dataset versions, and is designed to add a trace matrix that links design inputs and risk controls to those protocols and runs.

    Visit LabsOfScienceAll concepts

  • CrewFoundry

    Engineer, specialist and operator qualifications

    It records each person's skills and certificates. It is designed to show which engineers are trained on each model and procedure version, assign training when a procedure changes, and confirm that line operators are signed off.

    Technical detail

    Technical detail

    Its skills graph, learning paths, certificates and resourcing are the basis for showing which engineers and specialists are current on each model's procedure revision, with training assigned when a revision changes, and for operator sign-offs on the line.

    Visit CrewFoundryAll concepts

  • BuildMyIQ

    Customer operator training and certificates

    It runs courses and group sessions with short knowledge checks and issues certificates. It is designed to record attendance, set certificate expiry dates and show, site by site, which operators are trained.

    Technical detail

    Technical detail

    Courses, facilitator-led cohorts, assessments and certificates, with attendance and certificate expiry designed in, here tracking operator training by customer site and device model after an installation or a field notice.

    Visit BuildMyIQAll concepts

  • Botlit

    Complaint intake and cited service manual answers

    Its assistants are designed to take problem reports from customers and pass them to the complaint team, and to answer engineers from approved service manuals, showing the source. They are set up to turn down questions about patient care and pass them to a person.

    Technical detail

    Technical detail

    Agents are designed to take device problem reports from the customer portal and route them, to answer engineers from controlled service manuals with sources shown, and to decline clinical questions under a content policy and hand them to a person.

    Visit BotlitAll concepts

  • FluidGrids

    Hand-offs between reports, files, notices and people

    It passes news between products and people on a timetable or when a form or email arrives: turning reports into complaint files, sending safety notices and reminders, and chasing sites that have not replied. It also keeps BigConsole's figures up to date.

    Technical detail

    Technical detail

    Runs on schedules, forms, webhooks and a Gmail inbox to move reports into complaint files, runs notice, reminder and escalation workflows, and feeds scheduled results into BigConsole datasinks.

    Visit FluidGridsAll concepts

  • BigConsole

    Complaint trends and field action progress

    It turns complaint, field action and training figures into live boards that quality and service leaders can filter and drill into, with alerts designed to flag a problem reported more often than a set limit.

    Technical detail

    Technical detail

    Turns complaint, field action and training data into consoles with filters and drill-down, with threshold alerts designed to flag a failure mode whose count crosses a set limit.

    Visit BigConsoleAll concepts

One platform underneath: Burdenoff Workspaces

All eight products run on Burdenoff Workspaces: one sign-on for quality, engineering, production, service and clinical education staff, role-based access set once, a single audit trail across products, and one bill. Records are designed to link by serial number without extra accounts or exports.

Concept gallery

Every concept in this solution

15 concepts from 8 products. Each one links to its own page on the product's website, and every view has a link you can share.

Pitch kit

The Medical Devices solution in one minute

A device complaint never stays in one system. One report of a silent alarm reaches the unit's build record, the design file, the installed base, the service team and customer training. Burdenoff brings ManufacturedOps, AssetHandler, LabsOfScience, CrewFoundry, BuildMyIQ, Botlit, FluidGrids and BigConsole together on one workspace, so each question is designed to have one traceable answer by serial number, with a named person making every quality and regulatory decision.

  • Brings complaints from portal chat, email and service notes into linked complaint files, each with the unit's build history attached.
  • Gives production quality a serial-by-serial view of what is still open against the device master record, from firmware to labels.
  • Design changes are designed to arrive with the list of verification tests that must be run again.
  • Gives the field action team a view of every affected serial, from notice sent to corrected or not located.
  • Service visits and customer training are designed to go to people current on that model and procedure, with proof of who was trained.
Email it

Questions

Frequently asked

Are these products validated, or compliant with ISO 13485 or 21 CFR Parts 820 and 11?

No. The products are early and this page describes a design. Lab results can be signed and witnessed, and every product keeps a record of who changed what, but validating them for your use and any compliance decision stay with your quality team.

Technical detail

Technical detail

No such claim is made. The products are early, and this page describes a solution design. LabsOfScience notebook entries carry author, signer and witness; the other products keep attributable records and a shared audit trail of who changed what. Software validation for your intended use and any compliance determination remain with your quality organization.

Does the software decide whether a complaint is reportable or a field action is needed?

No. The complaint file is designed to gather the facts in one place. Whether an event must be reported, and whether to act in the field, are decisions your regulatory team and review board make and record under their own names.

Technical detail

Technical detail

No. The complaint file is designed to bring the facts together: the report, the unit's history, similar complaints and the returned-unit analysis. Whether an event must be reported to a regulator, and whether a field action is needed, are decisions your regulatory affairs team and review board make and record under their own names.

Will a Botlit agent give clinical advice to customers or device users?

They are not meant to. Botlit's assistants are designed to answer only from documents you approve, to turn down questions about patient care and pass them to a person. Your team reviews the documents and tests the assistant before use, and customer training covers how to operate the device only.

Technical detail

Technical detail

They are not meant to. Agents are designed to answer only from documents you approve, such as service manuals and instructions for use, to show the passages they used, and to decline questions about patient care and pass them to a person; your team reviews the documents and tests the agent before use. Customer training covers device operation as written in the instructions for use.

We already run a quality system, an ERP and a service management tool. Does this replace them?

No, not necessarily. You can make ManufacturedOps or AssetHandler the main record for a new line or service region, or run Burdenoff products alongside the tools you already use. FluidGrids can pass reports, serial lists and status updates between them.

Technical detail

Technical detail

Not necessarily. Some manufacturers may choose ManufacturedOps or AssetHandler as the system of record for a new line or a service region; others may run Burdenoff products alongside the tools they have. FluidGrids can move reports, serial lists and status updates between systems, and ManufacturedOps is designed for two-way ERP connections.

Do we need all eight products to start?

No. Most device makers would start where the pain is sharpest, for example ManufacturedOps and AssetHandler for build records, complaints and installed devices, and add the rest later. Everything runs on the same workspace, so records added later are designed to link to what is already there.

Technical detail

Technical detail

No. Most device makers would start where the pain is sharpest, for example ManufacturedOps with AssetHandler for device history, complaints and the installed base, and add design verification, service qualification or customer training later. Because every product runs on the same workspace, records added later are designed to link to what is already there.

Does this fit diagnostics makers as well as device makers?

Yes. An analyzer has a build record, installed units, service visits and trained operators just like a pump, and complaints about results are handled the same way. Reagent and assay lots can be traced as batches in ManufacturedOps.

Technical detail

Technical detail

The same pieces apply. A diagnostics analyzer has a device history, an installed base, service visits and trained operators, and complaints about results are handled and trended the same way. Reagent and assay lots can be traced as material lots in ManufacturedOps. Each organization runs its own workspace and decides who can see what.

Related domains

Where these products also work together

All domains

Want to explore this for your organization?

Tell us about your setup. We will walk you through the products involved and scope a pilot around the challenge that hurts most.

Talk to usBrowse every domain

This is a solution concept: it shows how Burdenoff products are designed to work together in this industry. The images are illustrations of the concepts, not screenshots of the actual products, and every name and figure in them is sample data.