Independent learning for medical-device professionals
SearchCommentaryConsulting
Worked Examples & Case StudiesMTL-402 · WORKED PRODUCT CASE STUDY

IVD Analyser

An end-to-end example showing how an automated laboratory analyser turns specimens, reagents, hardware and software into controlled patient results.

How to use this case study

This simplified example follows one result from sample loading to authorised release. Ask whether the instrument, assay, software, operator workflow and quality controls support the same intended claim without gaps between disciplines.

01

Case at a glance

A benchtop analyser performs a quantitative assay on prepared patient plasma. It identifies the specimen and reagent lot, controls incubation and mixing, acquires an optical signal, calculates a concentration, applies quality-control rules and presents the result for authorised review before transmission to a laboratory information system.

Clinical value

A timely quantitative result supports diagnosis and monitoring alongside other clinical information.

Product boundary

Instrument, consumables, assay configuration, embedded control, application software and defined interfaces.

Principal uncertainty

Whether the measured signal remains an accurate representation of analyte concentration across claimed conditions.

Operational dependency

Trained laboratory staff, environmental control, maintenance, calibration and external quality processes.

02

Define the claim before designing the analyser

Draft intended purpose

The system is intended for the quantitative in-vitro determination of a specified analyte in human plasma by trained laboratory professionals, to aid a defined clinical decision in the stated patient population. Results must be interpreted with clinical findings and other laboratory information.

The claim determines the specimen type, measuring interval, analytical performance, reference population and clinical evidence. A new specimen matrix or decision threshold is therefore a product change, not merely a new software configuration. Apply MTL-102 — Intended Purpose, Users and Use Environments.

03

Control the complete laboratory workflow

Pre-analyticalCollection, identification, transport, preparation and sample suitability
LoadingBarcode association, consumable checks and operator confirmation
AnalyticalDispensing, mixing, temperature, timing, detection and calculation
Quality controlCalibration status, control material, flags and acceptance rules
Post-analyticalReview, authorisation, reporting, audit trail and LIS transmission
SupportCleaning, maintenance, diagnostics, updates and complaint investigation

The analyser is only one part of the result-producing system. Interfaces and operator actions must be treated as design inputs, not assumptions left to the laboratory.

04

Turn the claim and workflow into requirements

  • The system shall associate each result with the correct specimen, assay, reagent lot, calibration and software configuration.
  • The analyser shall control temperature, timing, mixing and signal acquisition within defined limits.
  • Results outside the measuring interval or affected by identified interference shall be flagged and handled by defined rules.
  • An invalid or interrupted assay shall not be reported as a valid patient result.
  • Quality-control failure shall prevent or visibly qualify affected result release according to the approved policy.
  • Only authorised users shall approve, amend or transmit patient results.
  • Audit records shall preserve result, user, time, configuration and decision history.

Each requirement needs a source, risk relationship, acceptance criterion and verification method. See MTL-103 — User Needs and Design Inputs.

05

Risk analysis must reach the reported result

Specimen mismatch

A valid measurement is assigned to the wrong patient. Control identification, reconciliation, operator confirmation and auditability.

Biased result

Temperature, reagent, calibration or algorithm error produces a plausible but incorrect value. Control critical parameters and detect invalid states.

Suppressed warning

An out-of-range or quality-control flag is hidden during review or transmission. Preserve flags across every interface.

Interrupted assay

Power or communication loss leaves an ambiguous state. Abort safely, retain diagnostic evidence and require an explicit restart.

Connect analytical failure modes, use errors and software faults within one risk-management system using MTL-114 — Medical-device Risk Management.

06

Allocate control across hardware and software

The embedded controller owns deterministic motion, temperature and signal acquisition. The application software owns workflow, assay configuration, calculations, user interaction and result records. Controlled interfaces define commands, acknowledgements, timeouts, units, precision, error states and recovery. The LIS interface transmits only authorised results and preserves identifiers and flags.

A safe state completes only an immediately safe mechanical action, then stops the assay and prevents result release. Architecture and interface decisions should follow MTL-105 — Systems Engineering, Architecture and Interfaces.

07

Build one evidence programme

ANALYTICAL

Assay performance

Precision, bias, measuring interval, detection capability, interference, carryover, stability and specimen equivalence.

ENGINEERING

Instrument performance

Dispensing, motion, temperature, mixing, optics, environmental robustness, safety and maintenance.

SOFTWARE

Calculation and workflow

Algorithms, state transitions, configuration, access control, records, interfaces, faults and recovery.

USE

Representative laboratory use

Sample handling, loading, flags, quality control, maintenance, result review and foreseeable mistakes.

08

Follow one result-integrity thread

Clinical needProvide an accurate quantitative result within the claimed interval
Hazardous situationAn incorrect but plausible result influences patient management
ControlDetect invalid calibration, control and analytical states
ImplementationInstrument limits, software flags and release restrictions
VerificationBoundary, fault-injection, interface and configuration testing
ValidationRepresentative laboratories correctly interpret and act on states
09

Release a controlled system configuration

Transfer covers instrument build and calibration, consumable and reagent specifications, assay configuration, embedded and application software, installation qualification, service tools, training, supported LIS configurations and release records. The released combination—not an isolated component—is the product configuration.

10

Use a reagent-lot trend to test lifecycle control

Post-market monitoring finds a small positive bias associated with one reagent lot and high ambient temperature. The team must assess affected results and patients, verify traceability to installations and configurations, determine containment and reporting, investigate reagent and instrument interactions, and decide whether limits, software rules, labelling or field action must change.

The investigation combines vigilance, analytical performance, supplier control, software configuration and risk management. Use MTL-229 — Post-market Surveillance and Vigilance Specialists.

DISCUSSION

Questions to challenge the case

  1. Which parts of the result depend on the assay and which on the analyser?
  2. Where could a plausible result escape despite a failed control?
  3. Which configuration identifiers must follow every patient result?
  4. What evidence supports the claimed specimen type and measuring interval?
  5. Which faults require abort, warning or prevention of result release?
  6. What field trend would trigger reassessment of analytical performance?