Parallel Developments with different regulatory requirements (RUO etc)

Does anyone have any experience/tips with projects where a medical device software (MDR or IVDR) is also being released in a Research Use only context in a different region, I'm thinking mostly about how to manage things like requirements and specifications, especially if the RUO branch gets more rapid and frequent updates due to commercial pressures, with the expectation that there'll be "delta" updates to the regulated versions to catch up. What would be the most reasonable approach here, can it work to have side projects that rapidly deploy new features (including resulting bug fixes) and then at some later point go via a proper change control process to incorporate the newer stuff into the regulated product/documentation.

My advice is that there are two critical pieces of a 62304-compliant process to leverage:

1. The Software Configuration Management plan should be explaining how to handle branches (during life-cycle)
2. The Software Release process should be explaining how to handle releases, including releases form branches

This isn't telling you HOW to do either, but those are the parts necessary. Programmers can get really hung up on the SCMP details, so the advice here is to before setting the SCMP in stone is to have the development team explain what they (as individuals) need/want the SCMP to do... and then hold them to it. Otherwise the SCMP will end up being revised every time someone wants to stray off the path.

To expand slightly on point 1, it should establish the branching and merging strategy.

Thanks, but what about requirements, have you seen these written in a single requirements document (controlled by QA) with additional sections for the RUO, or as a separate document (or perhaps they can get their wish and keep those requirements to themselves within DevOps).

drm71 said:

Thanks, but what about requirements, have you seen these written in a single requirements document (controlled by QA) with additional sections for the RUO, or as a separate document (or perhaps they can get their wish and keep those requirements to themselves within DevOps).

Click to expand...

I'd as them how serious they are about the RUO portions. If the RUO functions are completely segregated in the architecture, and could be disabled with a compiler switch... I'd lean towards taking them seriously.

Haha, nice one
No, I think it's more the classic case of "RUO" = we can do what we want, and don't need to properly document anything. There's no separate functionality