Struggling to turn normative requirements into system/subsystem requirements

[Tidge]

Makes sense. However, you could also argue, that certain requirements (e.g. flammability) might apply to many or all subsystems, and are actually relevant. so, should we specify the same subsystem requirement for each?

And on a more practical level, how to let your documentation software (in our case: Polarion) know that a certain system level req. does not need to be broken down further? AFAIK, the traceability matrix will raise errors if a high-level req. does not have lower-level children reqs., and similarly, requires the verification of a system level req. to have all subsystem level verifications in place and passed, too.

60601-1 requires a risk management process; the RMP tells me which areas that have flammability as a concern and where to focus the efforts. A well constructed risk management file can act as a traceability matrix. One word of caution however: While a NRTL will do an assessment of the RMF for a device that undergoes 60601-1 certification, the folks at NRTLs don't typically grok RMFs, they will just end up doing the tests as they've pretty much always done. Similarly, NRTLs don't care what (99% of) the requirements used in development say.

As for the second part... @Peter Selvey explained in detail how engineering judgement and critical thinking comes into play. A (highly overconstrained) set of requirements isn't going to guarantee a device achieves 60601-1 certification. If the engineers literally don't know how to pick a power supply... or perhaps more likely, they don't know the difference between OTS power supplies... I *suppose* it is possible to avoid that embarrassment by (over-)specifying in requirements. However: If the engineering team is flubbing things like insulation, no-burn materials, fuses and power supplies... the project is doomed.

 

[Peter Selvey]

In terms of product standards and especially IEC 60601-1: it's a common approach to start the check early in the process, which sounds like a good idea to get on top of things early, but usually turns into a nightmare. The core reason is due to there being about 1500 discrete requirements in IEC 60601-1. In a final test report (for a ready to market device), about ~60% are N/A, ~30% are obviously Pass and ~10% need some more attention, ranging from a simple note, results of inspection, testing or other evidence. However, if you start working too early, about 50% is unknown, and many requirements are contingent on decisions elsewhere. You end up with large sections that are written up as might be applicable, probably not but better to keep it open just in case. And often many of the items are best left to the experts (test labs), like asking your accountant to handle your tax return, some stuff you need to know but other stuff you just let them fill out, no point explaining how the sausage is made. For example, Clauses like 8.1 and 13.1 are really just setting a framework, a test lab engineer would breeze through with a bunch of Pass and N/A while a design engineer could get bogged down as to what it all means.

How to know when is a good time to trigger a formal check? In my experience: when the IFU and labelling are 98% complete.

The instruction manual is usually left to last, and device labelling not much earlier. Everybody does it (me too). And yet, it is these items that drive a lot of the applicability decisions, tests and criteria.

Now, this does not mean closing your eyes to standards. Get them in the mix and make an effort to understand key areas that might impact the design. You can get a test lab or consultant involved and ask them to eyeball a prototype and give a heads up on possible issues, requirements to look out for. Is that perfect? No, but a systematic precheck for all 1500 requirements on a prototype without an IFU or labelling is not so useful either.

In my experience as a consultant (not looking for work here, I enjoy designing more!) most companies think they are "ready" but there is usually one or two more cycles left, which means there is plenty of time to address hidden or unexpected quirks from standards. In other words, don't panic, and better to concentrate on making a good product. For example, if a creepage distance is missed, chances are the PCB will need a rework due to functional problems, so plenty of time to move the traces around. Or come up with a clever solution to fix some other issue raised from standards. In fact, that's often where the joy is: those last minute solutions to unexpected problems, showing how smart us humans can be with a brain running on just 20W (compare to an AI trained using 1TWhr, and still gets it wrong). Think Apollo 13. I've seen it happen so many times (not just in the movies) and it's fantastic what solutions arise under pressure.

 

[hoshinari]

As a small follow-up regarding the struggle to keep traceability:

I have discovered that elsewhere in our TD, specifically the risk management, we have implemented some logic that allows a "risk mitigation measure" type work item to have one of two things linked to it: either a requirement (be it system or subsystem level), or a rationale why deriving a requirement and/or test for it is not required; for example,if the risk is mitigated by an entry in the IFU instead.
As long as a rationale is given, Polarion greenlights the measure.

We will try and implement the same logic for system level requirements that require no further breakdown. Worst case, if replacing a requirement with a rationale is not possible, we can still create one "dummy requirement" that just states "No derived subsystem requirements" or similar, and link to that.

 

[d_addams]

One potential way to approach this entire topic is to separate the system functions as 'safety', 'essential performance' and 'non-essential performance'. One treats call outs from standards as rationales for why the design will be 'free from a safety hazard' or 'appropriately ensure essential performance will be maintained'. I don't like treating compliance to a standard as a stakeholder need since its a rationale that the design choice is appropriate to fulfill the stakeholders functional needs. This does require really good system design and requirements flow down to the sub-system(s). An example of how this can work is the system requirement of 'freedom from flammability hazard' which gets assigned to the applicable sub-systems. For the assigned sub-system function of 'freedom from flammability hazard' then lists the 60601 languages as the mitigation. Since the language complies with a recognized standard it is considered to have met a risk reduction end point. This works really well with top-down analyses like Fault Tree. Less so for bottoms up since the requirements flow down not up.

How I think about this is no 'customer' would truly state 'the power supply meets 60601' as a need. Compliance to the standards are justifications for why the design is safe or will reliability perform the essential functions to generate benefit. Yes, yes there may be contracts and what not that call out standards compliance but those are just short cuts for 'we want it to be safe or state of the art and we want you to comply with 60601 so we know its safe'. This approach probably gets harder as the system gets more complex but I feel it addresses these types of concerns in a fundamental way so that its is clear what system function (including safety functions) are enable by compliance to normative standards.

 

[Tidge]

How I think about this is no 'customer' would truly state 'the power supply meets 60601' as a need. Compliance to the standards are justifications for why the design is safe or will reliability perform the essential functions to generate benefit.

No customer is going to ask that 14971 is adhered to during the development and on-market phase of a product, nor will they ask if the software was developed per 62304.

The basic safety requirements of 60601-1 (3rd edition) derive from a 14971 assessment... even if historically this is not how basic safety came about in 60601-1. If a medical device manufacturer follows 14971, they ought to get all of the basic safety requirements of 60601-1 (for medical electrical devices). If clauses of 60601-1 have to make their way into the RMF, they are probably better included (reworded) as test methods... for those parts of 60601-1 that are satisfied "by inspection", maybe those could be reworded into requirements... if they weren't too constraining of the possible design outputs.

I don't like treating compliance to a standard as a stakeholder need since its a rationale that the design choice is appropriate to fulfill the stakeholders functional needs.

It is literally the regulators who (effectively) require compliance to 60601-1 for medical electrical devices. They are the stakeholder in this case.

 

[hoshinari]

It is literally the regulators who (effectively) require compliance to 60601-1 for medical electrical devices. They are the stakeholder in this case.

I see it this way too. Our stakeholder requirements take into consideration

• The patient
• The operator
• The notified body that will greenlight the device
• Possibly the company/hospital/organization purchasing the device (they will definitely care about 60601 as part of their regulatory process)
• Possibly health insurance companies involved in subsidizing or similar
• Our own company

On that last point: I'm not in too deep with all regulatory processes, but as a medical device manufacturer under 13485, I can imagine that adherence to 60601 drops out somewhere in the company risk management process, too. But that's more of a philosophical question at this point

 

[Peter Selvey]

Generally the issues raised by IEC 60601-1 are valid issues, but the criteria is often feels too strict. For example, for 2MOPP @ 230V mains, IEC 60601-1 requires 8mm creepage which is typically on a PCB. Is this overkill? Absolutely. But just because the limit is overkill doesn't mean the issue itself is irrelevant, you need some degree of spacing between 230V mains and the patient. What limit should be applied? It could be argued case by case and say arrive at 4.5mm being the suitable criteria for a particular device. But then you have to convince everyone (not just regulators) that this is a reasonable distance. The designer says 4.5, but QA says 5.7, and the auditor thinks 6.2, and the NRTL 6.4. It's a huge overhead to apply to get everyone to agree. So why don't we develop a common specification that everyone agrees is OK, even if it has a bit of overkill? Oh, and let's call it an international standard, so everyone in the world agrees. I think the benefit of having a common specification is overlooked in the pain of compliance.

Of course, the 3rd edition's leaning in to many subjective requirements with no clear criteria kind of kills this argument, but that's another story!

 

[Tidge]

So why don't we develop a common specification that everyone agrees is OK, even if it has a bit of overkill? Oh, and let's call it an international standard, so everyone in the world agrees. I think the benefit of having a common specification is overlooked in the pain of compliance.

Of course, the 3rd edition's leaning in to many subjective requirements with no clear criteria kind of kills this argument, but that's another story!

I don't disagree with any of this!

 

[d_addams]

No customer is going to ask that 14971 is adhered to during the development and on-market phase of a product, nor will they ask if the software was developed per 62304.

The basic safety requirements of 60601-1 (3rd edition) derive from a 14971 assessment... even if historically this is not how basic safety came about in 60601-1. If a medical device manufacturer follows 14971, they ought to get all of the basic safety requirements of 60601-1 (for medical electrical devices). If clauses of 60601-1 have to make their way into the RMF, they are probably better included (reworded) as test methods... for those parts of 60601-1 that are satisfied "by inspection", maybe those could be reworded into requirements... if they weren't too constraining of the possible design outputs.



It is literally the regulators who (effectively) require compliance to 60601-1 for medical electrical devices. They are the stakeholder in this case.

correct 'effectively'. The requirement is the product is safe and effective, not that it complies with 60601. Meeting 60601 is the rationale that the specification/performance the device has yields a safe and effective product. Compliance with standards isn't the only way to achieve approval, it just happens to be the fastest way.

The reason to not start your inputs as the elements of the standard is the engineers lose sight of why that requirement is in place. If it is just for compliance to some standard then all of this stuff feels like busy work, non-value add paper pushing. This is why linking the performance requirements in the standard up to the true functional needs keeps the engineering logic intact. Yes this is not how people have been doing this for decades and it can really upset existing documentation strategies, but it helps engineers better understand the reasons requirements are present and the consequences of non-compliance on performance are not confounded by 'because the standard says so'.

I don't expect anyone will re-organize their approach based on this, but it is helpful to understand the nuance between standards compliance for compliance sake and how these came to be.

 

[hoshinari]

The reason to not start your inputs as the elements of the standard is the engineers lose sight of why that requirement is in place. If it is just for compliance to some standard then all of this stuff feels like busy work, non-value add paper pushing.

Very relatable, and well said.