5 ms·

13485 is relatively bureaucratic, but it's not required for FDA per se and there are things you can do. What is more problematic is IEC 62304 or similar, which

13485 is relatively bureaucratic, but it's not required for FDA per se and there are things you can do. What is more problematic is IEC 62304 or similar, which embeds a very particular SDLC into the development approach. It doesn't really fit AI/ML, it barely fits modern software development anyway.

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?
jdgiese 6y ago
We've had somewhat of a hard time applying agile to IEC 62304, although it's not impossible. This document has some useful tips: AAMI TIR45:2012 (R2018) Guidance On The Use Of AGILE Practices In The Development Of Medical Device Software Also, we have an open source offering that includes an IEC62304 compliant software plan. You can check this out here: https://github.com/innolitics/rdm/blob/master/rdm/init_files/documents/software_plan.md https://github.com/innolitics/rdm/blob/master/rdm/init_files...
- ska 6y ago
  details aside it's cool to see this done out in the open, that will really help people who have never seen it understand the scope.
  - jdgiese 6y ago
    Thanks! We think so too. It's a daunting task to go from ISO13485 or IEC62304 to a set of process documents. We hope to continue improving RDM to lower the barrier for researchers and startup founders in the space. We're about to add templates for a low-overhead QMS within the next week or two.
    - ska 6y ago
      > It's a daunting task to go from ISO13485 or IEC62304 It can be a bit overwhelming, especially the first time, and especially from scratch. I think for most people entering this space from a software point of view, the thing to get right first is some form of requirement management then later doc control. The QMS docs will come later too, but those two have the biggest impact on the engineering team itself.
  - yshrestha 6y ago
    Agreed. The standards are designed to be impervious to time and the implementations used. This has the unfortunate consequence of being quite abstract and difficult to grasp at first. For example "configuration management" was meaningless the first time I read it but really just translates to "version control" I think having an open source example will really help the concepts make sense to engineers implementing this for the first time.
oaiey 6y ago
62304 does not limit your choice of sdlc or agility. You just have to be able to read it. In generally, Developing with regulatory oversight and a real QA department is just very different. The agile manifesto speaks of "working software" over "documentation". It does not speak of code. It speaks about working software. In a regulated business "working software" includes a forest worth of hopefully digital paper and the code for your customers and oversight. The paperwork is part of the output here and not part of the self inflicted documentation.
- ska 6y ago
  That's a good way of putting it, but I would avoid pinning this on "regulated industry" Rather, in good engineering practice the design and process, etc. is part of the product. Regulated industries just put some expectations on what that means. This can be done well or poorly, but it's basically the intent. Don't read that the wrong way; I don't think every product benefits enough from good engineering practice to make it worthwhile - it certainly adds some friction and makes even "fast iteration" slower. On the other hand, it's absolutely the right way to approach things with high stakes for failures.
yshrestha 6y ago
Regulatory requirements usually does box you into a waterfall sdlc. However, that does not stop you from practicing an iterative sdlc internally. I like to conceptualize it as having a "waterfall shell with an iterative core" It is not uncommon for us to have new requirements added in the middle of a release. However, once safety testing and clinical validation are performed, changes are pushed to the next version unless a huge safety issue is detected.
- ska 6y ago
  > Regulatory requirements usually does box you into a waterfall sdlc. This really isn't true, at least not for this context.
  - yshrestha 6y ago
    I am not articulating myself correctly :) As far as regulatory submissions go and the design outputs that get stored in your QMS, the SDLC appears waterfall because there are clearly defined design inputs, design outputs, and verification / validation checkpoints. In practice, however, the actual process can be agile.
    - ska 6y ago
      Oh, I see what you mean, and yes I agree. I would word it differently, that the set of documents in your DHF, MDR, 510(k) filing, etc. are identical regardless of the methodology you use to create them. Some of the language around them sounds "waterfall-y" but you are perfectly welcome to iterate on these documents. The documents themselves are more about engineering practice than process, and are an output of whatever process you use, much like the software is.

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?

jdgiese 6y ago

We've had somewhat of a hard time applying agile to IEC 62304, although it's not impossible. This document has some useful tips: AAMI TIR45:2012 (R2018) Guidance On The Use Of AGILE Practices In The Development Of Medical Device Software Also, we have an open source offering that includes an IEC62304 compliant software plan. You can check this out here: https://github.com/innolitics/rdm/blob/master/rdm/init_files/documents/software_plan.md https://github.com/innolitics/rdm/blob/master/rdm/init_files...

ska 6y ago
details aside it's cool to see this done out in the open, that will really help people who have never seen it understand the scope.
- jdgiese 6y ago
  Thanks! We think so too. It's a daunting task to go from ISO13485 or IEC62304 to a set of process documents. We hope to continue improving RDM to lower the barrier for researchers and startup founders in the space. We're about to add templates for a low-overhead QMS within the next week or two.
  - ska 6y ago
    > It's a daunting task to go from ISO13485 or IEC62304 It can be a bit overwhelming, especially the first time, and especially from scratch. I think for most people entering this space from a software point of view, the thing to get right first is some form of requirement management then later doc control. The QMS docs will come later too, but those two have the biggest impact on the engineering team itself.
- yshrestha 6y ago
  Agreed. The standards are designed to be impervious to time and the implementations used. This has the unfortunate consequence of being quite abstract and difficult to grasp at first. For example "configuration management" was meaningless the first time I read it but really just translates to "version control" I think having an open source example will really help the concepts make sense to engineers implementing this for the first time.

oaiey 6y ago

62304 does not limit your choice of sdlc or agility. You just have to be able to read it. In generally, Developing with regulatory oversight and a real QA department is just very different. The agile manifesto speaks of "working software" over "documentation". It does not speak of code. It speaks about working software. In a regulated business "working software" includes a forest worth of hopefully digital paper and the code for your customers and oversight. The paperwork is part of the output here and not part of the self inflicted documentation.

ska 6y ago
That's a good way of putting it, but I would avoid pinning this on "regulated industry" Rather, in good engineering practice the design and process, etc. is part of the product. Regulated industries just put some expectations on what that means. This can be done well or poorly, but it's basically the intent. Don't read that the wrong way; I don't think every product benefits enough from good engineering practice to make it worthwhile - it certainly adds some friction and makes even "fast iteration" slower. On the other hand, it's absolutely the right way to approach things with high stakes for failures.

yshrestha 6y ago

Regulatory requirements usually does box you into a waterfall sdlc. However, that does not stop you from practicing an iterative sdlc internally. I like to conceptualize it as having a "waterfall shell with an iterative core" It is not uncommon for us to have new requirements added in the middle of a release. However, once safety testing and clinical validation are performed, changes are pushed to the next version unless a huge safety issue is detected.

ska 6y ago
> Regulatory requirements usually does box you into a waterfall sdlc. This really isn't true, at least not for this context.
- yshrestha 6y ago
  I am not articulating myself correctly :) As far as regulatory submissions go and the design outputs that get stored in your QMS, the SDLC appears waterfall because there are clearly defined design inputs, design outputs, and verification / validation checkpoints. In practice, however, the actual process can be agile.
  - ska 6y ago
    Oh, I see what you mean, and yes I agree. I would word it differently, that the set of documents in your DHF, MDR, 510(k) filing, etc. are identical regardless of the methodology you use to create them. Some of the language around them sounds "waterfall-y" but you are perfectly welcome to iterate on these documents. The documents themselves are more about engineering practice than process, and are an output of whatever process you use, much like the software is.