Software in Medical Devices, by MD101 Consulting

Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

The essential list of guidances for software medical devices

babel.jpg

This page gathers the guidances and other documents about CE mark and FDA 510k for software medical devices. I limited the list to documents, which have an impact on design.

Go to the list of MDD guidances

Go to the list of MDR guidances

Go to the list of FDA guidances


MDD 93/42/EEC CE Marking Guidances

I picked the documents in websites of the following organisms:

FYI: the International Medical Device Regulators Forum (IMDRF) replaced the Global Harmonization Task Force (GHTF) late 2012. Not a big deal for our subject. All GHTF documents are available on IMDRF website.

If you’re looking for documents about other steps of the software lifecycle (clinical evaluation & investigation, post-market surveillance and vigilance), you’ll find what you’re looking for in those websites.

Is your software a medical device?

The MEDDEV 2.1.6 Qualification and Classification of stand alone software contains information to let you determine if your software is a medical device. I hope for you that your software falls out of the scope of medical devices. You will save money! But I’ll be sad, because you won’t need to read my blog any more :-)

Has it a measuring function?

The MEDDEV 2.1/5 of June 1998 Medical Devices with a measuring function contains contains criteria which indicate that a device has a measuring function. Note that usually standalone software doesn't have a measuring function. If valid measurement data are given by another medical device, and are processed by the standalone software to compute new data, then it shouldn't have a measuring function.

What is its classification?

The MEDDEV 2.4.1 rev9 Classification of medical devices contains a comprehensive interpretation of the classification rules of the 93/42 directive.

Not yet sure of its classification?

Have a look at the last MDD version of the Manual on borderline and classification of medical devices. It has, amongst other things, a section about Picture Archiving and Communication Systems (PACS) and a chapter dedicated to mobile applications.

How should I proceed to CE mark?

The NB-MED 2.2/rec4 revision 5 Software and Medical Devices contains indications about how applying the annexes II to VII of the 93/42 CE directive.
This is explained with more details on the page How to qualify, classify, and CE mark Software.

How should I design it?

Official documents on CE mark are not talkative about software design. You have to rely on IEC 62304 standard (see posts in the "standards" category of this blog).
The FAQ on IEC 62304 of TEAM-NB gives a good bunch of recommendations to apply this standard for CE mark compliance. It also gives a lot of additional hints related to questions that are asked in this web page.

Outside Europe, the FDA published more that 10 years ago the "General Principles of Software Validation" guidance. The link to this very useful guidance is in the section about FDA guidances below on this page.

How to do clinical evaluation?

I put the clinical evaluation in the list hence it may have an impact on design. The MEDDEV 2.7.1 rev 4 Clinical evaluation - Guide for manufacturers and notified bodies contains recommendations about clinical evaluation.
The NBOG CL 2010-1 Checklist for audit of Notified Body’s review of Clinical Data-Clinical Evaluation is also interesting to see what is expected from the notified body during clinical data evaluation.

What information should I put in the technical file?

The NB-MED/2.5.1/Rec5 Technical Documentation contains the structure of the design dossier submitted (or not, if you’re in class I) to the notified body. It’s a very generic document and doesn’t contain a lot about software.
The GHTF SG1 N11 Summary Technical Documentation for Demonstrating Conformity to the Essential Principles of Safety and Performance of Medical Devices (STED) has some more information about software.
See also my templates repository page on design documents you should provide with your design dossier.
Furthermore, you may have a look at the NBOG_BPG_2009_1 Guidance on Design-Dossier Examination and Report to see what data notified bodies expect to find in your design dossier.

What do I put in the declaration of conformity?

If you do it by yourself (you’re in class I), the MDEG – 2009–12-01 Guidance notes for manufacturers of class I medical devices contains all information about CE mark of class I devices.
Have a look also at the NB-MED 2.5.1 Rec4 Content of mandatory certificates contains interesting information on what notified bodies want to see in the declarations of conformity of manufacturers.

How do I handle design changes?

This is a big issue with software, which are always perfectible and need to be continuously improved. The NB-MED/2.5.2/Rec2 Reporting of design changes and changes of the quality system contains information on when and how to report changes to design.
Have a look also at the NB-MED/2.5.1/Rec6 Renewal of EC Design-Examination and Type-Examination and the NBOG BPG 2014-1 Renewal of EC Design-Examination and Type-Examination Certificates. They both contain recommendations about when to decide to renew the design examination by a notified body. The first one is somewhat replaced by the second one, which is newer. However the NBOG BPG 2014-1 doesn't say that it supersedes the NB-MED/2.5.1/Rec6.

But the most interesting document on design changes was published in 2014: the NBOG BPG 2014-3 Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System. It contains the section 5.1 with lots of examples related to software changes.

Do I have to translate it?

Another really big issue for software, where translation may lead to design changes. The MDEG 2008-12- II-6.3 Mandatory Languages Requirements for Medical Devices is made for you.
Warning! It’s a bit old. You should have a look at the most recent regulations of member states. The advantage is if you find that a language is mandatory in this document, you won’t have to do further investigations.

Do I have to print the instructions for use?

The easiest way to deliver the IFU is to give it in an electronic format. The Regulation No 207/2012 gives information about when printing instructions is mandatory.
See also the NB-MED position about e-IFU.

MDR 2017/745/EU CE Marking Guidances

I picked the documents in websites of the following organisms, by order of importance:

If you’re looking for documents about other steps of the software lifecycle (clinical evaluation & investigation, post-market surveillance and vigilance), you’ll find what you’re looking for in those websites.

Is your software a medical device?

The MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 IVDR contains information to let you determine if your software is a medical device. I hope for you that your software falls out of the scope of medical devices. You will save money! But I’ll be sad, because you won’t need to read my blog any more :-)

Has it a measuring function?

The MDCG 2021-24 Guidance on classification of medical devices in section 3.1.6 contains criteria which indicate that a device has a measuring function. Note that even if accuracy of computations is important, standalone software may not have a measuring function. If valid measurement data are given by another medical device, and are processed by the standalone software to compute new data, then it shouldn't have a measuring function.

What is its classification?

The MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 IVDR contains an explanation of classification rules in annex VIII of the MDR.

Not yet sure of its classification?

Have a look at the lastest version of the Manual on borderline and classification of medical devices on this page, section "borderline devices". It contains, amongst other things, a section about Picture Archiving and Communication Systems (PACS), a section about scores (in class IIa or higher) and a few other sections dedicated to software and mobile applications.

How should I proceed to CE mark?

Have a look at the MDCG 2019-15 Guidance notes for manufacturers of class I medical devices contains indications on the bare minimum to do. If your software is in class I (lucky you) follow this guidance. If your software is in class IIa or above, read the guidance and look at article 51 of the MDR on what to do.
This is explained also on the page How to qualify, classify, and CE mark Software.

How should I design it?

Official documents on CE mark are not talkative about software design. You have to rely on:

  • IEC 62304 for medical device software lifecycle,
  • IEC 82304-1 for standalone software (aka Software as a Medical Device - SaMD),
  • Section 14 of IEC 60601-1 for embedded software (aka software in Medical Device - SiMD),
  • IEC 81001-5-1 for cybersecurity.

The FAQ on IEC 62304 of TEAM-NB gives a good bunch of recommendations to apply this standard for CE mark compliance. It also gives a lot of additional hints related to questions that are asked in this web page.
Cybersecurity is a new requirement for medical device software. The MDCG 2019-16 Guidance on cybersecurity for medical devices gives also high-level recommendations on cybersecurity management.

And if I have Artificial Intelligence?

This zone is darker than deep space (no Cosmic MDD Background radiation)!
No guidance to display here. Please, Rely on FDA guidances.

How to do clinical evaluation?

I put the clinical evaluation in the list hence it may have an impact on design. In absence of MDR specific guidance, the MEDDEV 2.7.1 rev 4 Clinical evaluation - Guide for manufacturers and notified bodies remains applicable and contains recommendations about clinical evaluation.
The MDCG 2020-1 Guidance on clinical evaluation (MDR) / Performance evaluation (IVDR) of medical device software brings new recommendations on how to proceed with clinical evaluation for software. You can also have a look at the MDCG 2020-5 Equivalence, if you want to compare your software to a competitor's one.

How do I manage UDI and Eudamed registrations?

The primary source of requirements on UDI for software is the annex VI section 6.5 "Device Software" of the MDR. Here you will find how to assign a UDI to your software for a new version, for minor and major changes.
See also the guidances on UDI and Eudamed on the MDCG guidances page

What information should I put in the technical file?

The annexes II and III of the MDR contain the structure of the design dossier submitted (or not, if you’re in class I) to the notified body. It’s a very generic structure and doesn’t contain a lot about software.
The GHTF SG1 N11 Summary Technical Documentation for Demonstrating Conformity to the Essential Principles of Safety and Performance of Medical Devices (STED) is old but can still be a source of information about software.
See also my templates repository page on design documents you should provide with your design dossier.

The Best Practice Guidance for the Submission of Technical Documentation under MDR for Team-NB describes what should be present in a technical file. But it is not a game changer for software.
Furthermore, even if it's only applicable to the MDD, you may have a look at the NBOG_BPG_2009_1 Guidance on Design-Dossier Examination and Report to see what data notified bodies expect to find in your design dossier.

What do I put in the declaration of conformity and how do I CE mark my software?

Simply look at the annexes IV and V of the MDR. Note that for standalone software without hardware media, the CE mark logo can be placed in an "About" window dialog.

How do I handle design changes?

This is a big issue with software, which are always perfectible and need to be continuously improved. See the MDCG 2020-3 Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD. This guidance is however specific to changes to software previously MDD CE marked.

The most interesting document on design changes was published in 2014 under the MDD regime: the NBOG BPG 2014-3 Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System. It contains the section 5.1 with lots of examples related to software changes. It is still interesting since no such MDCG guidance has been published yet.

Another document on changes was published by the Team-NB: the Position paper for the interpretation of device related changes in relation to a Notified Body Opinion. Curiously, this document is well done for software, but rarely referenced by Notified Bodies.

Do I have to translate it?

Another really big issue for software, where translation may lead to design changes. The Overview of language requirements for manufacturers of medical devices is made for you.
The document warns you that you should have a look at the most recent regulations of member states. The advantage is if you find that a language is mandatory in this document, you won’t have to do further investigations!

Do I have to print the instructions for use?

The easiest way to deliver the IFU is to give it in an electronic format. The Commission Implementing Regulation (EU) 2021/2226 on electronic instructions for use of medical devices is applicable. Note: the previous regulation 207/2012/EU on e-IFU is still referenced in the annex I article 23.1.f of the MDR. But new newer one 2021/2226/EU is actually the applicable one with the MDR.

Here's my list so far for MDR CE mark.


Let's see now the FDA 510k guidances for software.

FDA 510k Guidances

I picked all the documents on FDA's website: medical devices guidances search page
This is my unique source of information. Compared to what is found about CE mark, the FDA has the immense virtue to gather all the precious information! I think that FDA guidances are a little verbose. But their content is always of good level and may be used to find answers on subjects that EU guidances don’t tackle.

What is the classification of my device?

Classification of devices is most of times straightforward, with the help of the FDA database on classification of medical devices. However, things are changing quickly for software with the rush of medical devices manufacturers on new software applications, for which a predicate may be difficult to find. To manage this, we have 6 guidances explaining the regulations:

That's a lot of information. That's the result of the 21st Century Cures Act, voted by the US Congress in 2016. You'll have to read them all and find the case relevant to your software.

But wait, my software does a lot of things, how do I manage this

If your software contains several modules or sub-systems, some of them may not be qualified as medical devices, and may not be regulated by the FDA. In this case, read the guidance on Multiple Function Device Products - Policy and Considerations.

How do I design it?

Surely the most important document of the FDA about software design (after the CFR, of course!), is the Content of Premarket Submissions for Device Software Functions
This guidance defines the documentation level. Read this carefully. It has a significant impact on the design documentation.
You can also read the General Principles of Software Validation; Final Guidance for Industry and FDA Staff. It is one of the most comprehensive documents about software design, verification and validation in the medical devices industry. It covers all steps of software design and more. Yet a bit outdated, it remains a must-read!

And if I have Artificial Intelligence?

Not a lot of information on AI/ML yet. Especially on design, like interpreting IEC 62304 or more generally software design documents for AI/ML.
You will find (better than nothing):

What about COTS and SOUP?

COTS (Components Off The Shelf) are software not developed internally. COTS include software found at runtime and software used for design. For example: COTS include java runtime and java SDK.
IEC 62304 standard defines the concept SOUP (Software of Unknown Provenance) as software used in the medical device, but not developed with the level of scrutiny required by regulations. The SOUP definition doesn't include software used for design. For example: SOUP include java runtime only, but not java SDK.
The guidance on Off-The-Shelf Software Use in Medical Devices deals with problems about hazards brought by this kind of software.

What about human factors engineering?

Human factors in a recent subject of concern of regulation agencies. FDA is not the last one in the race for new guidance about it with the Guidance on Applying Human Factors and Usability Engineering to Medical Devices.
This guidance integrates the latest developments on usability engineering found in IEC 62366-1 and AAMI HE75 standards.
There is also a long page on FDA website dedicated to human factors.

What about cybersecurity?

Software security is a non-functional requirement, which is probably the most difficult to implement if software wasn’t initially designed the right way. There are two documents on cybersecurity while designing software medical device.
The first one is the guidance on Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions . It is not easy to apply as it defines a cybersecurity management process.
The second document is the guidance about Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software. Its scope is narrower as it focuses on problems about updating COTS software (like installing a patch delivered by the COTS editor), which have impact on security.
A third guidance is in draft state: Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act. Despite its cryptic title, it is just the latest FDA's views about cybersecurity documentation.
The last guidance on cybersecurity deals with phases after design, when software is placed on the market: the Guidance on Postmarket Management of Cybersecurity in Medical Devices.
There is also a page on FDA website dedicated to cybersecurity.
On the recognized standards side, you can apply:

  • IEC 81001-5-1 (IEC/TR 60601-4-5 isn't recognized),
  • AAMI TIR 57 and AAMI TIR 97 guides on security risk management, and
  • AAMI SW96 on security risk management process.

What about clinical evaluation?

You're not lucky and you have to perform a clinical evaluation, e.g. when you have to go through the De Novo conformity assessment process. Have a look at the guidance Software as a Medical Device (SAMD): Clinical Evaluation
FYI, this guidance is the copy/paste of the IMDRF guidance on the same subject.

Do I have to print the instructions for use?

The guidance on Acceptable Media for Electronic – Product User Manuals contains new information about cases where delivering user manuals in printed format is mandatory. If you fall out of the scope of mandatory print copies of instructions for use, enjoy.

What do I put in my 510k submission ?

FDA gives instructions about medical devices in general in the web page titled Content of a 510(k).
Not much about software on the page. You have to rely on the guidances mentioned above about design and cybersecurity.

My device changes, should I submit a new 510k ?

The guidance on Deciding When to Submit a 510(k) for a Change to an Existing Device contains a very well done decision tree and a lot of explanations with new information about software. This guidance is for all types of medical devices, a new guidance specific to software was also published by the FDA: Deciding When to Submit a 510(k) for a Software Change to an Existing Device. Rely on this last guidance when changes are made in software.



First version on February 22nd 2012
Second version on October 29th 2015.
Updated on August 2016
Reason: periodic review of articles
Fixed dead links and updated guidances info.
Updated on July 2020
Reason: periodic review of articles and addition of MDR
Fixed dead links and updated guidances info.
Updated on March 2024
Reason: periodic review of articles
Fixed dead links and updated guidances info.

Published on Wednesday, 22 February 2012 by Mitch