© robyn mackenzie Embedded | February 29, 2016

Standards key to safeguarding your healthcare investment

With several healthcare products facing delays in recent years, Anthony Giles, Managing Director of Blackwood Embedded Systems, believes it is time to rethink the way software is documented and tested during product development.

Anthony Giles
Anyone who has worked on bringing a new product to market understands the importance of proving the concept early on.

Typically, this not only needs to be achieved within a limited budget; the developer is also under enormous pressure to get a working prototype ready to show to existing and potential investors.

However, realistic investment phase planning from the outset is essential.

From a software point of view it is coding the task that has visible outputs to investors and board members. Yet this typically makes up only 30% of the complete process.

For medical products, it is the documentation and evidence gathering process, rather than the technology, which is the critical path to achieving the CE mark.

As well as having significant implications on development time, not getting the paperwork in place quickly enough can result in companies having to start all over again or failing.

Moreover there is a balance that should be struck between demonstrating a working prototype to investors and ensuring the product is ultimately market ready.

As well as ensuring companies have a working version of the product quickly , I believe that by establishing a documentation baseline early, companies also have a set of notes demonstrating their understanding of the basic principles or product outline from the outset and how these have historically changed.

Additionally it shows why and how these requirements have been specified, the risks associated with each and how these will be verified and validated for accuracy and to ensure the product is compliant and safe.

To make this process as smooth as possible, it is essential to embrace industry standards – particularly IEC 62304: 2006.

IEC 62304: 2006 defines the life cycle requirements for medical device software and is used to establish a common framework for medical device software life cycle processes.

Whilst many companies have expressed concerns around the formalised structure and requirements, those that embrace the set of processes, activities, and tasks described in this standard, are actually able to bring products to market without unnecessary or unanticipated delays.

Food and Drug Administration (FDA) guidance also says this is the “least burdensome approach”; although this is a phrase that is often misunderstood with many associating the standard with extra time and costs.

It is time we clarify this.

As well as many white papers on the subject, every formally trained engineer is taught that planning and breaking your design down into simpler blocks results in easier to understand systems and correctly resourced projects.

This reduces software bugs - a major time/ money waster in projects, and results in safer designs by aiding identification or risk management early on and not having to rework software due to incorrect architecture implementation.

By following 62304 it is possible to achieve both time and cost savings - hence why the FDA rightly calls this the “least burdensome approach”.

I believe it is also essential to correctly identify the Safety Class early in the project.

With 62304 defining the medical devices software classed as either A, B or C where:
  • Class A: No injury or damage to health is possible [FDA –Minor level of concern]
  • Class B: Non-Serious Injury is possible [FDA – Moderate level of concern]
  • Class C: Death or Serious Injury is possible [FDA – Major level of concern]

The 62304 standard does not state how to determine this. However, the FDA provides an easy to follow tick box questionnaire in its “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices[1]”.

It is important to understand the full software lifecycle and documentation required to meet the CE mark for the products and avoid any unnecessary risks of failure arising from not having them.

SOUP (Software Of Unknown Provenance) as described by 62304 and the OTS (Off The Shelf Software) as described by the FDA, can save time and be very useful for getting technology uncertainty addressed early on.

However there should be a word of caution here.

The software safety class will also dictate the potential use of SOUP. Class A software where for example there would be no restrictions as failure of the SOUP by definition cannot harm the patient or user in any way.

In Class C however you would have to seriously consider not using it as it would take more time, or in some cases be impossible to, validate the safety of the software.

In conclusion, investors should not be fooled by a fully working prototype; check the paperwork process has been followed or assume at least another 18 months to market.

Author: Anthony Giles, Managing Director of © Blackwood Embedded Systems


Please note the following: Critical comments are allowed and even encouraged. Discussions are welcome. Verbal abuse, insults and racist / homophobic remarks are not. Such comments will be removed.
Further details can be found here.
Load more news