In today’s healthcare industry environment, software is increasingly a part of some, if not all of the medical devices created to solve modern problems. There is increasing emphasis on simulating, diagnosing, solving, and intervening with injuries and illnesses. This makes a lot of sense as traditional surgical and pharmaceutical interventions often had side effects due to the patient’s unique differences. Companies are increasingly trying to come up with systems that can review all different parameters to make the best decisions, requiring software to iterate these solutions.
The common question is always ‘why doesn’t X, known for the best software in the consumer world solve this problem with the best engineering resources they have available?’. While this sounds like a simple solution, there are two potential problems with this strategy. First, companies that are generating revenue and market share from consumer goods report to a group of stakeholders, often eager to see new products introduced to the market in the shortest time possible to maximize revenue while minimizing the cost. Second, the culture of ‘move fast and break things’ and agile development don’t quite mesh with the regulated world of ‘plan, plan some more, define risks, and set requirements and don’t make any changes on the fly without replanning’ world. You quite quickly see the problem. Engineers and programmers are interested in working for a company where they can grow, develop and put their names on the next app and are not much interested in writing protocols and documentation for the medical device that’s going to run a robot correctly every time, or diagnose with no major risks that can’t be just debugged on the fly.
The software as a medical device requires a 90/10 approach. Ninety percent of the time, we need to write up a development plan, identify needs of the customer or user, list all the risks that can affect these needs, set requirements to determine how we test for these risks to show they are sufficiently mitigated, and write reports to document and prove we have done the work. All the while writing SOPs and WIs to show how we go about doing these tasks. Tedious, yes, but important as the end use can literally mean life and death.
Both the FDA and EU MDR cite IEC 62304 as a useful standard to model medical device software development. The general premise is the generation of a software development plan that includes when the software is written, how, and with what tools, how it’s modified, and what the structure of the code looks like to ensure that a unit based verification and validation study can be conducted. The basic units of code can be as broad and as narrow as necessary to ensure that any unintended outcomes in the field can be investigated in a piecewise fashion to conduct a sound failure mode analysis and a corrective action plan can be drawn to address the issues. The first step in software planning is the assessment of risk levels. For this, there are three buckets identified by the regulatory bodies: no risk to the patient, some risk of injury, and potential risk of death or serious injury. Depending on the levels, the detail of documentation both prior to, and as a result of the development efforts varies from limited to very detailed, respectively.