HAZOP is a structured team technique that walks every node of a system and applies guidewords such as NO, MORE, LESS, REVERSE, and OTHER THAN to each design parameter. It originated in the process industries and is heavily under-used in MedTech, but for drug delivery, diagnostic fluidics, and connected systems it surfaces hazards that FMEA and FTA routinely miss. EN ISO 14971:2019+A11:2021 permits HAZOP; ISO/TR 24971 lists it among recommended techniques.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • HAZOP stands for hazard and operability study. It is a deviation-guideword technique defined in IEC 61882 and referenced in ISO/TR 24971 as an analysis method permitted under EN ISO 14971.
  • The method breaks a system into nodes, identifies the design intent for each node, and systematically applies guidewords to each parameter to surface credible deviations from intent.
  • HAZOP is powerful for medical devices where flows, doses, concentrations, timings, or energy levels drive safety. Drug delivery systems, infusion devices, dialysis systems, and sample-handling diagnostics are natural fits.
  • HAZOP is under-used in MedTech because the standard reference culture centres on FMEA. Tibor has seen HAZOP surface hazards in early reviews that FMEA later missed entirely.
  • A notified body will accept HAZOP as a technique provided the study is documented, the team composition is appropriate, and the outputs feed the risk management file consistent with EN ISO 14971.

Why this matters

Most MedTech risk files are FMEA files. Tibor's audit experience shows a predictable consequence: the hazards the file surfaces are the hazards an FMEA is good at surfacing, component-level failure modes and their immediate effects. What FMEA is not good at surfacing is operability deviations in systems where flow, dose, timing, or concentration are the primary safety parameters.

Take a simple example. A drug delivery pump is designed to deliver 5 mL of a concentrated therapy over 30 minutes. An FMEA walks every component: motor, valve, sensor, syringe, tubing. For each one, it lists failure modes. Motor stalls. Valve leaks. Sensor drifts. Useful rows, but none of them ask the HAZOP question: what if the flow rate is HIGHER than intended? What if it is LESS? What if it is REVERSE? What if the drug delivered is OTHER THAN specified, because the wrong reservoir was loaded, or because of a software label mismatch?

HAZOP asks those questions systematically. It does not rely on the team remembering to think about them. It forces the team to think about them by walking a table of guidewords against every parameter at every node. Felix's observation from coaching medtech startups is that the first time a team runs a proper HAZOP, they spend the first thirty minutes uncomfortable and the next two hours realising how much their FMEA had been missing.

HAZOP is not a replacement for EN ISO 14971:2019+A11:2021. It is a technique inside the process the standard defines. This post explains what HAZOP is, where it fits in MedTech, and how a founder running a lean risk management programme can use it without building a process-industry bureaucracy around it.

What MDR actually says

The MDR does not reference HAZOP by name. MDR (EU) 2017/745 Annex I General Safety and Performance Requirements 1 to 9 requires risks to be identified, evaluated, and reduced as far as possible, and the residual risks to be acceptable against the benefit to the patient. Annex II requires the risk management file to be part of the technical documentation.

EN ISO 14971:2019+A11:2021 is the harmonised standard for risk management under the MDR. It establishes the process. It is technique-agnostic. The manufacturer picks the techniques appropriate to the device.

ISO/TR 24971 is the informational technical report that accompanies EN ISO 14971. It lists HAZOP alongside FMEA, FTA, preliminary hazard analysis, and event tree analysis as examples of techniques that can support hazard identification and risk analysis under EN ISO 14971. ISO/TR 24971 is not a harmonised standard. It is guidance. Notified bodies treat it as authoritative interpretation.

The HAZOP technique itself is defined in IEC 61882. IEC 61882 describes the method: break the system into nodes, state the design intent for each node, apply guidewords to each parameter, and document credible deviations with their causes, consequences, existing safeguards, and recommended actions. The symbols, the table layout, and the facilitation approach are in that standard. A notified body auditor who sees HAZOP in a medical device risk file will expect the study to be consistent with IEC 61882 conventions.

The plain-language translation: the MDR and EN ISO 14971 let the manufacturer choose. ISO/TR 24971 names HAZOP as a legitimate choice. IEC 61882 defines how HAZOP is actually done. The manufacturer who uses HAZOP has to document the study the way any structured risk analysis is documented, and has to link its outputs to the risk management file.

A worked example

Consider a startup building a benchtop drug reconstitution and delivery system for a hospital pharmacy. The device draws sterile diluent, mixes it with a lyophilised drug, and delivers a measured dose to an IV bag. The critical parameters are volume of diluent, mixing time, drug concentration after reconstitution, delivery flow rate, and air in line.

The team divides the system into nodes. Node one is the diluent draw. Node two is the mixing chamber. Node three is the concentration verification step. Node four is the dose delivery into the IV bag. Node five is the air detection and purge.

For each node, the team states the design intent. Node one: draw exactly 10 mL of sterile diluent at room temperature in under 15 seconds. Node four: deliver 100 mL of reconstituted solution into the IV bag at a flow rate of 20 mL per minute.

Then the guideword walk begins. The facilitator calls out each guideword and the team considers the parameter under it.

At node one, the parameter is volume. NO volume means the diluent draw failed entirely. Cause: empty diluent reservoir, blocked inlet, broken pump. Consequence: reconstitution does not happen, no drug is delivered, patient does not receive therapy. Safeguard: pre-draw volume check. Action: add a minimum-volume sensor on the reservoir.

MORE volume means the pump draws more diluent than specified. Cause: calibration drift, sensor fault. Consequence: drug concentration is too low, under-dose delivered to the patient, clinical failure. Safeguard: concentration verification at node three. Action: widen the pass-fail window on the concentration check to catch concentration deviations caused by diluent volume errors.

LESS volume means under-draw. Cause: similar to MORE but in the other direction. Consequence: concentration too high, over-dose risk, potentially severe depending on the therapy. Safeguard: concentration check. Action: tighten the pass-fail window on the high side.

REVERSE flow at node one is particularly interesting. Cause: pressure differential, valve fault. Consequence: contaminated mixing chamber contents could back-flow into the sterile diluent reservoir, compromising sterility of all subsequent doses. Safeguard: one-way check valve. Action: verify check valve presence and add periodic sterility testing of the reservoir.

OTHER THAN at node one means a liquid other than the specified diluent was drawn. Cause: wrong reservoir loaded by operator, labeling error, cross-connection during setup. Consequence: the wrong reconstitution, wrong drug behaviour, unpredictable patient outcome. Safeguard: none in the original FMEA. Action: add a mechanical key system that prevents wrong reservoir connection, plus a barcode scan at reservoir load.

That last one is the point Tibor makes repeatedly. OTHER THAN at node one is an operability hazard. It is not a component failure mode. FMEA would not have surfaced it because no component failed. HAZOP surfaced it because the guideword forced the team to ask whether the liquid in the reservoir might be something other than specified. A real device recalled in the past for exactly this failure mode would have been caught by an early HAZOP.

The study continues through every node, every parameter, every guideword. The output is a HAZOP table with hundreds of rows. Most are closed with "existing safeguard adequate". Some surface new actions. Those new actions feed back into the risk management file, into the design, and into the usability study.

The Subtract to Ship playbook

HAZOP has a reputation for being heavy. It earned that reputation in petrochemical and nuclear contexts where a formal HAZOP can take weeks with a full-time facilitator. A medtech startup cannot afford that. Felix and Tibor recommend a scaled version.

Step one. Choose HAZOP scope narrowly. Do not try to HAZOP the entire device. Identify the one or two subsystems where the dominant safety parameters are flow, dose, timing, concentration, energy, or temperature. Those are HAZOP's sweet spot. Other subsystems stay in FMEA.

Step two. Assemble a small multidisciplinary team. Four to six people is right. Include development, clinical, usability, regulatory, and one person from manufacturing or supply. Tibor's observation from the interview: the best hazards come from the people who are not the lead engineer. Different disciplines surface different guideword consequences.

Step three. Facilitate the session with a prepared node list and guideword table. Do not invent structure on the fly. IEC 61882 defines the facilitation approach. A lean version is a two-day workshop for a narrow scope. That is an order of magnitude less than process-industry HAZOP, and it is enough for most medtech subsystems.

Step four. Document every deviation considered, even the ones closed as non-credible. The audit trail matters. A notified body will sample rows and ask why they were closed as non-credible. "The team discussed and agreed" is not a sufficient answer. "Closed because existing design feature X prevents the deviation, verified in test report Y" is sufficient.

Step five. Cross-link HAZOP outputs into the risk management file. Every HAZOP row with a recommended action becomes a risk control that needs verification. Every HAZOP row closed as acceptable becomes a residual risk statement. The standalone HAZOP document is not enough. It must feed EN ISO 14971's risk management file.

Step six. Schedule a HAZOP refresh whenever a change in the subsystem changes the design intent at any node. HAZOP is not a one-time artefact. Design evolution should trigger node-level reviews.

The subtraction here is refusing the petrochemical-industry scale. Take the technique, scale it for a startup's resources, and use it where it pays. Ignore it where FMEA already does the job.

Reality Check

  1. Do any of your device's primary safety arguments depend on flow, dose, concentration, timing, or energy staying within a specified window? If yes, HAZOP probably belongs in your toolkit.
  2. Has your team ever sat through a structured guideword walk of any subsystem in your device? If no, you have not yet seen what HAZOP surfaces.
  3. Can you point to at least one hazard in your risk file that was surfaced by a technique other than FMEA?
  4. When a guideword like REVERSE or OTHER THAN is applied to the inlet of your delivery or sample-handling subsystem, can you immediately name the safeguard that prevents the deviation?
  5. If a notified body auditor asks why HAZOP was or was not used on your drug delivery subsystem, is the answer documented in the risk management file?
  6. Has a multidisciplinary team, not just engineering, reviewed the operability deviations of your device?
  7. Does your design change process trigger a HAZOP node refresh when the design intent of a node changes, or does the original study become stale?

Frequently Asked Questions

Is HAZOP required under EN ISO 14971:2019+A11:2021? No. The standard is technique-agnostic. HAZOP is one of several techniques ISO/TR 24971 lists as appropriate. The manufacturer picks based on the device.

Can HAZOP replace FMEA? Not usually. HAZOP is strong where flow, dose, timing, and energy drive safety. FMEA is strong where component-level failure modes drive safety. Most devices benefit from both.

How long does a HAZOP session take for a medtech subsystem? A scoped HAZOP on a single subsystem with a prepared node list can be done in one or two days with a five-person team. Broader scope takes longer. Resist the temptation to HAZOP the entire device in a single sitting.

Does a notified body expect IEC 61882 compliance? A notified body auditor who sees HAZOP expects the study to follow recognised HAZOP conventions. IEC 61882 defines those conventions.

Is HAZOP useful for software-only devices? It can be. Applying guidewords to data flows, state transitions, and timing parameters in software architecture can surface hazards that functional testing misses. It is less mature in software contexts than in hardware, but Tibor has seen it work.

Who facilitates the HAZOP session? Ideally someone who has facilitated before and is not the lead designer of the subsystem. Independence matters. If no one in-house has facilitated a HAZOP, consider bringing in external facilitation for the first session and building the skill internally.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I General Safety and Performance Requirements 1-9, Annex II technical documentation.
  2. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices. Harmonised standard.
  3. ISO/TR 24971. Medical devices. Guidance on the application of ISO 14971. Technical report, informational.
  4. IEC 61882. Hazard and operability studies (HAZOP studies). Application guide.