Software Engineering in a regulated environment
Lately we’ve been working with many of our clients on the challenges of developing software for FDA-controlled products. From combination product companies developing tools for physicians to medical device companies developing new interfaces on mobile platforms, we’re finding that many of the problems encountered are universal.
Simply put, development teams brought in with significant mobile and web app experience clash with an organization built around FDA approval. It seems as if the two groups don’t even speak the same language, and that’s because they don’t. Software teams have a hard following SOPs, which leads to a clunky and tiresome process of ‘importing’ in the software into a company’s design controls process after-the-fact, which is non-ideal from a process and submission standpoint.
Modern software development is:
- Comfortable with requirements in flux
- Geared toward rapid iteration and cycle time
Whereas medical device, pharma and biotech development is:
- Wants requirements to be static
- Out of necessity, geared toward long periods between iteration and lengthy cycle time
These two mentalities may on the surface seem like incompatible opposites, but there are ways of integrating the two. I’ll provide two examples here.
First, properly constructed requirements at the system level should allow for flexibility in developing the software without showing constant flux in the DHF that would alarm an auditor or submission reviewer. Second, whatever agile process or software tool the software team is using should be able to export a snapshot of the requirements at any given time (perhaps at the beginning of each sprint). This can be inserted to the DHF as needed to show continuity and control during the development process.
For more on this topic, or if you’re interested in having Suttons Creek assist with your software development, contact us at email@example.com