3 ms·

You can avoid it for class I, but generally 13485 is becoming more harmonized and required. I don't think 62304 is too hard to adapt; i haven't done the proces

by ska 6y ago

You can avoid it for class I, but generally 13485 is becoming more harmonized and required. I don't think 62304 is too hard to adapt; i haven't done the process work in a while but unless the latest rev radically changed things it isn't very prescriptive, not nearly as much as you suggest; I've seen agile and Agile variants done. It is a sign of the slowness of the process that it's only recently become required, and reflects 15-years ago thinking, but it's fine. You are right that a lot of modern development processes need a fair bit of tweaking, but it's mostly because they aren't nearly careful enough for device use. This may be a bit of a burden on pure software devices, but it's probably the right trade off overall. This is why the big shift in thinking for most developers will be the 14971 (risk management) adoption, not 62304 itself (IEC 62304 punts to ISO 14971 for this part, but it's common with hardware dev)

yshrestha 6y ago
Interesting. I do agree 62304 seems to mostly codify what we would consider best software principles anyway. Your statement about 14971 being the big shift in thinking is interesting. With a bit of clinical context, do you think developers can write code with risk management in mind?
- ska 6y ago
  > With a bit of clinical context, do you think developers can write code with risk management in mind? Absolutely. Some people with more of a hardware bent are probably used to FMEA - but that requires a design to evaluate. Risk management approach (should) starts at the other end, while you are still understanding what your product should do. If you do 14971 right (and iteratively), it will help you pin down key requirements up front that will help you avoid missteps that are costly to recover later. One of the big shifts is that it makes you think about uncommon/incorrect usages earlier, as well as thinking about how other systems could mess with you.
  - yshrestha 6y ago
    I agree risk management should start at the patient and work backwards to the individual units that themselves can be inputs into an FMEA. When the design gets a bit further along, you can perform an FMEA and repeat the process several times over the course of the design. I am always surprised at how many more risks can be identified by doing the process iteratively and frequently. Do you recommend any tools that have helped you perform risk analysis?

by ska 6y ago

yshrestha 6y ago

Interesting. I do agree 62304 seems to mostly codify what we would consider best software principles anyway. Your statement about 14971 being the big shift in thinking is interesting. With a bit of clinical context, do you think developers can write code with risk management in mind?

ska 6y ago
> With a bit of clinical context, do you think developers can write code with risk management in mind? Absolutely. Some people with more of a hardware bent are probably used to FMEA - but that requires a design to evaluate. Risk management approach (should) starts at the other end, while you are still understanding what your product should do. If you do 14971 right (and iteratively), it will help you pin down key requirements up front that will help you avoid missteps that are costly to recover later. One of the big shifts is that it makes you think about uncommon/incorrect usages earlier, as well as thinking about how other systems could mess with you.
- yshrestha 6y ago
  I agree risk management should start at the patient and work backwards to the individual units that themselves can be inputs into an FMEA. When the design gets a bit further along, you can perform an FMEA and repeat the process several times over the course of the design. I am always surprised at how many more risks can be identified by doing the process iteratively and frequently. Do you recommend any tools that have helped you perform risk analysis?