What are the requirements for a software as a medical device?

Related resources:
See all resources

What are the requirements for a software as a medical device?

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.

Explore solutions with a Nemedio expert
Schedule a Call

What’s a Rich Text element?

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

What’s a Rich Text element?

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

Test caption

What’s a Rich Text element?

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

What’s a Rich Text element?

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

  • sgsgdsg
  • sgdsgsgdsg
  1. sgsgdsg
  2. sgdsgsgdsg
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Vivamus suscipit tortor eget felis porttitor volutpat. Pellentesque in ipsum id orci porta dapibus

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

1.

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

The Nemedio Blog:  Demystifying Compliance

your guide to product development and compliance for medical technology

What are the requirements for a software as a medical device?

June 27, 2022

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.

RELATED

Chat with an Expert

Stuck on a particular problem? Speak with an expert to get your questions answered.