Select Page

The regulations set forward in the Medical Device Directory require the technical file to demonstrate that the device has been created in accordance with the ‘state of the art’.  In other words that you’ve done something that can be recognised as a good job.

Fortunately there’s some handy standards that are considered to represent the state of the art, so if you comply with the standards, you’re in a good position.  It’s worth clarifying that the regulations do not directly require compliance with the standard. If you feel you can demonstrate you’ve done a good job by other means, that’s fine.  However it’s generally easier to show compliance to the standard and work from there.

For software, there are five standards you should be familiar with:

  • ISO 13485.  This is the general standard for medical devices and describes what a Quality Management System needs to be to ensure compliant medical devices are produced.
  • ISO 14971. This standard describes how to manage risks relating to medical devices.
  • IEC 62304 is a specific standard for medical device software.  It covers software which is part of a medical device.
  • IEC 82304 specifically considers standalone software as a medical device.  
  • IEC 62366 looks at how to evaluate the usability of your software.

That’s a lot of reading!

But here’s a very high level overview of what you need to do.

  1. Write a company Quality Management System (if you don’t already have one).  It should provide:
  • A company quality statement.  Something that commits the organization to taking quality seriously
  • A document management system that allows significant documents to be identified, tracked and approved
  • A development process that describes how software is developed and deployed in your organization
  • A verification and validation process.  Verification is testing that you build the software right.  Validation is testing that you built the right software
  • A supplier management process (especially if you are using sub-contractors to write your software)
  • A HR policy which covers how you provide training to your staff so that they understand their responsibilities and obligations under the system
  • A Post Market Surveillance process.  How you continue to check and evaluate that your software is working correctly after you’ve released it.  In particular how you react if someone informs you that they have suffered harm from your software.
  • A Continuous Improvement process which captures ideas of how to improve things and implement those improvements
  1. Define the intended purpose of your device.  This is very important. The better you define the purpose, the easier it will be to demonstrate you’ve considered all the risks associated with that purpose, and that you’ve mitigated them.
  2. Assess the risks.  Since there’s a whole standard just for this, you can tell it’s important.  The basic process is:
  • Identify all the risks you can think of
  • Assess the risks in terms of the potential harm your device could cause to its users
  • Assess how likely that harm is
  • Think of ways to reduce the harm (either how likely it is to occur or how bad it will be if it does happen).  These are called mitigations
  • Assess the risks after you’ve reduced the harm by implementing the mitigations
  • Assess whether the mitigations have themselves introduced new risks of harm
  • Assess whether, after all the mitigations, the benefits to people of using your system outweigh the remaining potential risk of harm.
  1. Write down the requirements for your device.  As much as possible, demonstrate that these really are requirements, and not just something you made up to justify developing your device.  In particular, demonstrate there is evidence that if your device does what it claims, this has a clinical benefit to users (this is called a clinical evaluation).
  2. Define how you’re going to verify that your device actually does what your requirements say it should, and nothing else.  Also demonstrate that you’ve proved this is the case. We usually do this by writing tests, linking the tests to the requirements, and then providing evidence those tests have been performed and passed.
  3. Gather evidence that you are working in compliance with your Quality Management System.  This can be the results of internal audits, records produced by the work as it is being done or logs output by tools you use.

When you’ve done all these things you can assemble your technical file.  There is a sort of standard for the format of technical files, prepared by the Global Harmonization Taskforce and called Summary Technical Documentation (STED).  This does provide some helpful guidance on how to structure your technical file, but it has no official standing as such. Complying with STED will not guarantee that your technical file will be accepted, but it is a useful guide and reminder.