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:
Whereas medical device, pharma and biotech development is:
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
Risk analysis is a key component of any complex engineering endeavor, but is particularly so when considering technology that may be life sustaining (or life-threatening when something goes wrong) such as many medical devices.
Indeed, there is an entire ISO standard dedicated to guiding the medical device manufacturer on how to design a risk management systems, and increasingly additional standards mandate a continuous risk management process as well.
As any manufacturer begins a risk analysis for a product or component of a product, the first step is necessarily to identify what the risks are, before they can be categorized by safety and occurrence. And though the process may be embellished via various SOPs, it usually amounts to putting a cross-functional product team in a room in brainstorming various potential risks, guided either by formal documentation (FMEA, FTA) or experience (as in the case of a clinical or sales representative who has substantial experience observing customers use the product).
But this is a mistaken approach. Even a well-meaning effort, with a very good team comprised of representatives throughout the company and people who have seen 100’s of customers is going to suffer from absence blindness. Without a structured process for risk identification, the risk analysis will suffer.
So what does that process look like? We’ll explore this in a series of posts on our blog, but as a teaser, it needs to start with evaluating the following sources:
We’ll cover what we mean by each of these, starting with Use Cases, in a later series.
Watch this space for SCI’s thought leadership in the development of medical devices, combination products, and the application of systems engineering to complex projects.