Let me put you on stage for few seconds. One day you woke-up and you have THE idea.
“I will develop a medical software or an “app” (for my young audience lol) that will save lives and I will sell it quickly and I’ll become rich.”
Hold on! Let’s analyze this sentence in detail.
You will create a piece of code (Software) and with it you will do something (algorithm or analyze or prediction…) and if all goes well this can save people’s life. But if your software makes a wrong job because you misinterpreted some information, then people can die or get heavily injured. So you’ll get to jail and ruin your life.
Alarm, Alarm..!!!
It sounds like what you are trying to develop is a Medical Device Software.
If you are not sure just change the word “Software” by the word “Product” to see how it sounds… Yes, it’s a Medical Device Software.
Let’s make some arrangement to this sentence. I think you missed something but I am sure we’ll figure out what.
Let me rephrase
Ok, after some thinking, here is my proposal.
“I will develop a medical software or an “app” that will hopefully save lives (if this passes all the clinical studies that I will plan to do to confirm that my piece of software is really saving them) and will submit it to a Notified Body for evaluation to obtain the CE mark.
But before that I need to build my Quality Management System following the standard ISO 13485 and develop this software following the right specific standard as IEC 62304, IEC 62366, IEC 60601 (Look chapter “Quality Standards for SaMD”).
And if it will pass the certification and arrive on the market I will need to monitor the software regularly through Post-market Surveillance. For any changes that is affecting the software, should update the risk analysis that I developed following ISO 14971.
And I will get audited every year by my Notified Body. And maybe twice a year because possibly I will get an unannounced audit….. Then I’ll be happy”
Does it not sound better. I think it’s perfect. It looks like the 10 commandments to follow to develop a Medical Device Software.
“Ok, I’ll maybe not do that finally”
Why? Your idea looks really great.
You should not give up on your dream. Let me help you to clarify your path to succeed.
What is here for you
Within this article, I will try to teach you how to identify if your software is a Medical Device and what you should consider in that case to be able to place it on the market.
For more advanced readers, I also linked to one of my article that I wrote on Clinicaltrialsarena.com on the Clinical Evaluation of Softwares.
I have also included some support for software development as there are different standards to consider.
So a lot of items to cover.
Table of Contents
What to do before to start to develop a Medical Device Software?
Before to start to develop a software related to healthcare, please read this article. It can save you time and refocus your product.
Because if you are not a Medical Device Specialist, hire one to help you as you cannot imagine how the way will be long and uncertain.
But first I will show you on a high level the way you’ll have to follow to certify your medical device software.
What is a Medical Software?
But to be correct we should call it a Software as a Medical Device or SaMD. Let’s review the definition.
What is the definition of a Software as a Medical Device or SaMD?
If you have a look at the definition on the IMDRF website (International Medical Device Regulators Forum) it says:
“Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
An app is falling under this definition. It can be provided on any phone (Read later for specific Wellness and Fitness Apps).
Computer desktop software can also be SaMD.
A piece of monitoring equipment that contains already the software inside is not a SaMD. But it’s still software for the Medical Device Regulation EU IVDR 2017/746 and EU MDR 2017/745.
Examples of Software as a Medical Device (SaMD)
I think you need to see some examples to really understand what is a SaMD. So here are some examples coming from me. But I will also include the list coming from the guidance:
- Software that is processing a patient image to detect diseases like cancer
- Treatment planning app that supply information to a patient
- Algorithm to Detect Atrial Fibrillation
- The algorithm interprets Myocardial Infarction
- EEG Analysis
- Coronary Physiological Simulation Software
List from MDCG 2019-11 - Guidance on Qualification and Classification of Software
Recently the MDCG released a Guidance where more examples of Software as Medical Devices are listed. Let me summarise that for you:
- Independent Software
- Medical Device Software (MDSW) that uses maternal parameters such as age, the concentration of serum markers and information
obtained through fetal ultrasound examination for evaluating the risk of trisomy 21. - MDSW that receives measurements from transrectal ultrasound findings, age, and in vitro diagnostic
instruments and calculates a patient’s risk of developing prostate cancer. - Mass Spectrometry MDSW intended to analyze LC-MS/MS data to be used for microorganism
identification and detection of antibiotic resistance. - MDSW smartwatch app, which is intended to send alarm notifications to the user and/or health
practitioner when it recognizes irregular heartbeats for the purpose of detecting cardiac arrhythmia.
- Medical Device Software (MDSW) that uses maternal parameters such as age, the concentration of serum markers and information
- Software that drives or influences a hardware Medical Device
- Melanoma image analysis software intended to drive a near-infrared laser light scanner.
- MDSW intended to measure and transmit blood glucose levels, calculate insulin dose required and
drive the insulin pump to administer the calculated dosage (closed-loop insulin delivery system).
- Software as a Medical Device wherever it is located (Cloud, computer, mobile…):
- MDSW is intended to operate a point of care test from a remote location.
- Software used by Healthcare Professional of Layperson:
- MDSW that provides insulin dose recommendations to a patient regardless of the method of delivery
of the prescribed dose, whether via an insulin pump, insulin pen or insulin syringe.
- MDSW that provides insulin dose recommendations to a patient regardless of the method of delivery
- Software that is driving or influencing the use of a Medical Device
- Software that is intended to be used to operate a clinical chemistry analyzer.
- Software with built-in electronic controls for IVD quality control procedures. These quality control
procedures are intended to provide users with assurance that the device is performing within
specifications.
So as you can see we are not talking about Medical Device QMS software or Registration software. On the guidance MDCG 2019-11, it is also mentioning that software making a simple search on a database (Library function) to retrieve information is not qualified as a SaMD.
Same for software used for invoicing, staff planning, emailing, web or voice messaging, data parsing, word processing, and back-ups.
Those are more a support tool for a Medical Device Company. But more about software that by themselves are considered as Medical Devices and placed on the market to be used by healthcare professionals, patients or consumers.
The 3 steps to prepare your Medical Device Launch
This is the model I am promoting for any medical device certification. So I want you to use it to succeed on your Medical Device launch.
I consider that to start the preparation of a Medical Device development, you need to follow those 3 steps at the beginning.
Without this I am not sure that you will arrive “Right the first time” to your objective.
You have an idea of a software, let’s confirm if really you have to follow the path of a Medical Device.
This is one of the most important thing. This will define all the following activities you have to do. This can also remove a lot of burden if you confirm that your software is class I.
As you will see, a software can have many classes. And for each class some options are provided to you for the certification.
Choose first the option you want to go for. This will provide you your shopping list. Then you’ll have only to collect the required information.
Now that you know the process, let’s dig on Step 1.
Step 1: Is my Software a Medical Device?
I wrote the article “What is a Medical Device?” on it. Have a look to understand this for any medical device.
It shows you the definition of a Medical Device in Europe and even in other countries like USA, Brazil and China.
Software vs Medical Device Definition
Your software should comply with the definition of a Medical Device to be considered as a Medical Device in Europe.
And as always, I’ve said to myself “Why you don’t create a tool that is helping a bit”. So to check that quickly I developed a tool called “Is my product a Medical Device?”
You’ll have just to answer few questions and at the end it will tell you if your product is a Medical Device and even if it is active or implantable or custom-made. Cool no!!
What you need to know is that on the definition of a Medical Device there are some new words that appeared in comparison to the MDD 93/42/EC.
Here is the abbreviated definition as all don’t talk about software. And I’ll highlight those words.
Definition
‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
- diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
- diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
- investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
- providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations,
Analyze
Good, any software that is predicting or providing a prognosis on a disease is a Medical Device.
I imagine that Artificial Intelligence era is not too far. I am really interesting to learn more on this. Specifically on how they will validate an Artificial Intelligence Software.
I suppose that this will be done with a lot of clinical trials and see if the predictions of the digital brain is correct. I am impatient to dig on this.
Ok, you have all the tools in hand.
With this you will define easily if you are part of the beautiful Medical Device Community. And If you are, “Welcome, you will have a lot of fun with us.”
MDCG 2019-11 Decision Steps to Qualify a Medical Device Software
By reviewing the MDCG 2019-11 guidance, I can see a Decision Tree graph to qualify a Software as a Medical Device. I’ve created an infographic out of it. I hope this will be helpful.
What about Fitness or Wellness apps?
I did always try to interpret the regulation about those apps that we have on our phones and that track our steps, ask us to eat more this or less that. At one point they are helping us to be more healthy.
And I discovered something and I am sure you’ll be surprised. It’s specifically said on the MDR 2017/745 that those apps are not Medical Devices.
I know what is your next question. Where is this?
It’s at the beginning of the regulation. You know, this is on the first part where there are a lot of text but that we never read. Usually we start to read at Article 1.
We assume that before article 1 it’s only a some disclaimer or some context information about transition from MDD 93/42/EC. But NO. There are also a lot of information there.
Here is the specific paragraph
(19) It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device.
The qualification of software, either as a device or an accessory, is independent of the software’s location or the type of interconnection between the software and a device.
Cool! I am sure you learned something.
Summary
Let’s review quickly where we are
We finished Step 1: Is your product a Medical Device? And your answer is yes.
If it’s No, you can stop here. No need to struggle with the rest. Unless you want to learn, which is the objective of Easy Medical Device.
Step 2: What is my Medical Device Software classification? - Rule 11
For Software as a Medical Device classification, you’ll need to follow the exact same process to put it on the market as an implantable device or a simple scalpel.
Then “What is the class of my Medical Device Software in Europe?”
For Software, this one can be tricky. But with the new Medical Device Regulation (EU MDR 2017/745 Annex VIII) there is a full section on software.
So we should find our way easily.
In the case you are asking yourself, “How to classify a Medical Device in Europe?”, you are lucky. I created a video on that (Check below).
Video on Medical Device Classification
Subscribe to my Channel
I even created a blog post, a classification form, infographics. So no excuses.
Now, specifically on the classification for Software as a Medical Device, there is only 1 rule that exist (Unless your software is part of an hardware) which is rule 11.
And when you look at it, your software can be classified from class I to class III. So really the full possibility.
Let’s list them:
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes
I suppose that software then receives data from an equipment and run some maths to predict which disease you have or what kind of medicine you should take enter to this category.
Then it’s class IIa
Except if such decision have an impact that may cause a serious deterioration of a person’s state of health or a surgical intervention
This is the intermediate state where the patient gets a serious injury or a surgery. So his state can still be reversed. It’s class IIb
Except if such decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health
This one is difficult. Because on your risk analysis you have to define what kind of disease you can diagnose and define if this disease can lead to major damage on your body.
As this is riskier it becomes immediately class III
Summary
- The first statement is the baseline → Class IIa
- The second statement is the intermediary status (cause serious deterioration or a surgical intervention → Class IIb
- The third statement is the highest risk (cause death or an irreversible deterioration of a person’s state of health → Class III
Software intended to monitor physiological processes
I don’t know if this is applicable to SaMD. I see more something like a Monitoring equipment in the hospital to check your heart beat… I don’t see a software without specific hardware doing that.
I remember that an application exists to check your pulse just by putting your finger on the camera lens. Maybe such an app would be under this rule.
So such software is class IIa
Except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient.
I would ask which physiological parameter is not vital for a patient. I suppose heat beat. Maybe oxygen on the body… The issue with this one is that it’s not easy to define. I really think you need a Medical Doctor to help assess the risk of your device if not performing well. “ISO 14971 is called at the reception”
But the same as before, I don’t think this is applicable to SaMD.
In the case you find an example that is applying to this rule, then it will be a class IIb
All other software are class I
So if your software is not providing information used to take a decision or propose some therapeutic advice, and, also not monitoring physiological parameters, then you are good for a class I (Lucky you).
With the next step, you will understand that the classification of your Software is key. It’s even critical in the case you make a mistake as you’ll never be able to get certified.
So if you are not sure, contact your notified body. They are not a consulting company but can give you some tips.
Podcast Episode - Rule 11 for Software devices
Subscribe to my Youtube Channel to get notified of my next videos
Step 3: Which conformity assessment route to follow?
Last step. We are not far from success. Keep reading as you have still a lot to learn.
Now you know that your software is a Medical Device. You know your class so what?
You need to define your conformity assessment route.
If you are not familiar with this, let me explain quickly making an analogy to school.
To put your product on the market, you have kind of an exam to pass. And to pass this exam you’ll need to prepare some documentation.
Depending on your grade, you’ll need to prepare more or less documents. And more your grade is high more requirements you have.
Now I’ll show you the different route you can take knowing your product, it’s classification and which option you want to choose to pass this exam.
You can demonstrate conformity through many ways
What is following are some hints on what you can use to show conformity. This is a list of activities, or references that you can use and which are valid and accepted by the notified bodies.
Presumption of Conformity
- Article 8 – Conformity through Harmonized Standard (European Commission)
- Article 9 – Conformity through Common Specification
Other means of Conformity
- Annex II Section 4 – Controlled documents demonstrating conformity
Technical Documentation
- Annex II & III – Documenting conformity includes all information on design, evidence and manufacturer’s procedures; PMS plan
So during your journey, if some justification are required to prove that you are compliant, you can use those possibilities.
Now let’s see which exam you’ll have to pass to obtain the CE mark.
Depending on the class
What will follow is what is expected from you to obtain your certification.
For each class there is a list of requirements to be provided. And some of the classes give you a choice.
And there are some easy route where you have to assess by yourself that you are compliant (For really low risk devices)
And majority of the routes where you need to appoint a Notified Body (Certification company) to obtain the certificate.
Let’s review the list for each class.
Class I (Self assessment)
- Technical Documentation and QMS (Annex II & III)
- Declaration of conformity (Article 19 and Annex IV)
Class IIa (Notified Body assessment)
- Annex IX – Quality Management System
- Article 52 Para 6 – Assessment of Technical Documentation of a representative device for each category
- Declaration of conformity (Article 19 and Annex IV)
Class IIb (Notified Body assessment)
- Annex IX – Quality Management System
or
- Annex X & XI – Type examination and production QMS
+
- Article 52 Para 4 – Assessment of Technical Documentation of a representative device of each generic device group
- Declaration of Conformity (Article 19 and Annex IV)
- Annex II & III – Technical Documentation and QMS
Class III (Notified Body assessment)
- Annex IX – Quality Management System
or
- Annex X & XI – Type examination and production QMS
+
- Annex II & III – Technical Documentation and QMS
- Article 52 Para 3 – Assessment of Technical Documentation
- Declaration of Conformity (Article 19 and Annex IV)
Same as for class IIb, Subsequently to article 52, you have to prepare a Technical File for your products.
- Annex II & III – Technical Documentation and QMS
I voluntarily removed anything that has nothing to do with an SaMD.
So don’t use this list for all the other devices. To make it easy for you, I decided to focus on the Software as a Medical Device.
Differences between each route
What I like when I see the different route is to analyze the difference for each class.
I see that for Class I and IIa, there is no real choice on how to assess your product. There is only one way.
For class IIb and III the regulators are giving you some choices.
But I always see that there will be the QMS, the Technical Documentation assessment and the Declaration of conformity.
Always create your Route Plan
What is interesting with this exercise is that you plan your route to market. You define step by step what you need and already assign task to clarify the demande or to get the information. It takes more time for sure.
I know that some of you may read this article when they have already developed the product and discover all the struggle to market it as a Medical Device. So now you have to go back and create documents retrospectively.
All what you defined now is a high level information for your project but for me I like to see the full Map. I know where I want to arrive but for most companies the difficulty is how to get there. With this I know also which way to take.
If you are hiking, you know what I mean. You look at a Map and ask yourself “Should I take this way or this one” One can kill your journey when the other can make it successful.
Ok, you know that your software is a Medical device which opens the way to a Medical Device certification in Europe.
You know the class of your product which is an indicator of its risk but also helps you to see what kind of certification you can choose.
And finally, because of the conformity assessment (Route plan) you know what type of data or document you need to register your product.
If you look for an Authorized Representative or an Importer for the EUROPEAN REGION don’t hesitate to contact us at Easy Medical Device.
We can represent you in the EU, UK, and Switzerland.
GDPR for your Medical Device Application
You are developing a Medical Device software (MDSW) and now you are thinking to collect personal data of European Citizen.
I would recommend then to think twice or to read the GDPR regulation which entered in for in May 2018.
This General Data Protection Regulation is not only for medical devices but fo all products or applications that collect Personal Data.
On the Medical Device made Easy Podcast I have interviewed Jovan Stevovic from Chino.io who explained to us the importance of GDPR with MDR.
Subscribe to my Youtube Channel to get notified of my next videos
Quality Management System (QMS) for your Software
I hope you noticed it. On the Conformity Assessment part, it says that for any class you need a QMS.
Do you know what is a QMS?
I wrote a blog post on “Frequently Asked Question on ISO 13485:2016” which is the Quality Management System I recommend. But inside you’ll see that I am talking about the other ones.
So it’s worth to read.
A Quality System means that you need to create your Quality Manual, your Procedures and the Documentations that belongs to them. Still some work to do.
Hold on, I am not done. This is only the basis. It means that this is what any Medical Device Company should do.
Quality Standards for SaMD
But for Software companies there are few other standards I advice to follow.
Here is the list:
- Software Lifecycle management – IEC 62304
- Usability – IEC 62366
- Risk Management – ISO 14971 (Specific to Medical Devices and not only software)
- Safety – IEC 60601
On the Software Lifecycle Management standard, you’ll have all the information on when you need to execute validation or verification. So keep it up.
If you are developing a software, create procedures that are reflecting these standards. Then I’ll promise that you will be on the right way.
As I’ve said, I prefer you to take more time to prepare the way and launch later than launch a product that will crash because you got blocked by an authority.
Understand IEC 62304
If you are trying to develop a Software as a Medical Device then this standard is key for you.
You should apply IEC 62304 and in this episode of the Podcast Adnan Ashfaq will provide you with key information.
Don’t forget to download his giveaway from the show notes.
How to implement IEC 62304?
The steps that a Software Medical Device company should take to implement IEC 62304, the international standard for the development of medical device software, would include the following:
Conduct a risk assessment: The first step in implementing IEC 62304 is to conduct a thorough risk assessment of the software medical device. This will help identify any potential hazards and the associated risks, and to ensure that the software development process is designed to minimize these risks.
Develop a software development plan: The next step is to develop a software development plan that outlines the processes and procedures that will be used to develop the software medical device. This plan should be based on the risk assessment findings and should be tailored to the specific needs of the software medical device.
Develop a software verification and validation plan: This step involves developing a plan for verifying and validating the software medical device. The plan should include the methods and techniques that will be used to verify that the software meets the requirements, and to validate that the software is safe and effective.
Conduct software testing: The software should be tested to ensure that it meets the requirements and is safe and effective. This testing should be conducted according to the software verification and validation plan.
Obtain regulatory clearance or approval: Once the software has been developed and tested, the software medical device company should seek regulatory clearance or approval. This will involve submitting the software development plan, the software verification and validation plan, and the test results to the relevant regulatory authorities.
Continual maintenance: The software medical device should be continually maintained, updated and monitored to ensure that it continues to meet the requirements of IEC 62304, and the regulatory requirements.
It’s important to note that the implementation of IEC 62304 can be a complex process, and it is advisable to seek the help of experts in the field, and to have a project plan with clear milestones and timelines.
Additionally, it’s important to stay updated with the latest version of the standard and the regulatory requirements for software medical devices in the countries where the company plans to market its product.
Podcast Episode 11
On the below episode of the Medical Device Made Easy Podcast, I interview Bill Stamm and Rafael Blanco on how to succeed in Software Validation.
This would be a great resource for you to go on a more advanced level.
Do you ask yourself "How can I get MDR certified?"
Software as a Medical Device - Clinical Evaluation
To plan your approach to the Clinical Evaluation process of a SaMD.
The IMDRF has also issued a guideline for that.
The clinical evaluation process is defined in 3 pillars:
- Valid Clinical Association
- Analytical Validation
- Clinical Validation
See below the figure extracted from IMDRF website “Software as a Medical Device (SaMD): Clinical Evaluation” document.
The main exercise is to look if the link between the output of the Software and the Clinical Condition is accurate, reliable, precise.
The objective is to confirm that your software is really doing what you promised.
Article on Clinical Trials Arena - Clinical Evaluation for a SaMD
Here is my review on “Clinical Evaluation for Software as a Medical Device”. Have a look.
Video: Sufficient Clinical Data approach
Cybersecurity
Cybersecurity will be one of the major threats to this Software industry. And even more, if healthcare is on the equation.
What if bad people can access some healthcare data or be able to control some devices.
The EU MDR is asking you to also take into account this threat by having some actions in place to test your product for Cybersecurity.
The MDCG issued a guidance for that which helps you to define how to be compliant within your Cybersecurity threats. It is MDCG 2019-16
Below are also some standards that you may consider:
- IEC TR 60601-4-5:2021: Safety related technical security specifications for medical devices
- IEC 62443-3-2:2020: Security for industrial automation and control systems – security risk assessment for system design
- AAMI TIR57:2016 : Principles for medical device security – Risk Management
- ISO/TR 24971: 2020 : Guidance on the application of ISO 14971:2019
- IEC 81001-5-1:2020 : Health software and health IT systems safety, effectiveness and security – Security – Activities in the product life cycle
- UL 2900-2-1:2018 – Software Cybersecurity for Network-Connectable Products – Requirements for Healthcare Systems
- FDA Cybersecurity guidance
- DIN 80001-1:2010 – Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software – Application of risk management.
You may need to understand what are the potential risks for your company associated with your Medical Device that is under Cyberattack.
This includes:
Loss or theft of sensitive patient information: Medical devices often store and transmit sensitive patient information, such as medical histories and treatment plans. If this information is accessed or stolen by a cyberattacker, it can lead to serious privacy breaches and financial fraud.
Disruption of device functionality: A cyberattack on a medical device can cause it to malfunction or become inoperable, which can have serious consequences for patients who rely on the device for treatment.
Injury or death: In some cases, a cyberattack on a medical device can lead to injury or death. For example, a cyberattacker could alter the dosage settings on a device that administers medication, which could result in an overdose or other adverse reactions.
Loss of trust in the healthcare system: A cyberattack on a medical device can damage the reputation of the healthcare organization that uses the device, and lead to patients losing trust in the healthcare system.
Legal Consequences: Cyberattacks on medical devices may lead to legal consequences for healthcare organizations and manufacturers, as they may be held liable for any harm caused by the attack.
Financial Consequences: Cyber attacks can cost organizations and manufacturers significant amounts of money. This can include the costs of investigations, lawsuits, lost revenue and reputational damage.
There are several ways to protect you against cybersecurity threats, including:
Regular software updates and patches to address known vulnerabilities.
Implementing strong authentication and access control measures to prevent unauthorized access to the device.
Using encryption to protect sensitive data stored on the device.
Regularly monitoring the device for unusual activity and implementing intrusion detection and response measures.
Conducting regular security assessments and penetration testing to identify and address potential vulnerabilities.
Adhering to industry standards and guidelines for medical device cybersecurity, such as those set by organizations like the FDA and the NIST.
Creating a incident response plan in case of a cyber-attack.
Regularly training employees and end-users on how to identify and report potential cybersecurity threats.
Pitch
We know that one of the threats that exist to medical devices is cybersecurity. You may be all-seeing some movie episode where a hacker is taking the control of a hospital and stopping some machines to work. Or someone that can control the pacemaker of a patient.
This is not fiction but reality. We will talk today with Stefan Bolleininger from Be on Quality about the way you need to prove to the authorities about your cybersecurity. The new EU MDR 2017/745 is requiring you to have some tests done to show that your device cannot be attacked by a hacker.
Another source: Podcast Episode
We have discussed of Cybersecurity with Erik Vollebregt on this Podcast Episode.
TÜV SÜD webinar on Cybersecurity
And recently, Dr Abtin Rad from TÜV SÜD has presented the situation for Cybersecurity on this video.
Certification
Alleluia, you’ve made it. You have a Medical Device developed following all the standards mentioned and your Technical File is perfect.
Just an info.
You can say Alleluia, only if your product is class I.
Why?
Because you are self-certifying your product. (Watch my video on “How to classify a Medical Device in Europe? (MDR 2017/745)” I talk about that.
Let’s review now what you’ll need to do if your product’s class is bigger than class I.
What about Softwares under Class IIa, IIb or III?
Now if you are Class IIa, Class IIb or Class III. You have still some work to do.
First, you need to choose a Notified Body. I advice you to choose it as soon as you’ve completed the Conformity Assessment part.
The Notified Body is a company that received an accreditation to deliver you the CE Mark or the ISO 13485 certification.
You’ll need to choose carefully. On my article “FAQ on ISO 13485:2016” I give you some advice on how to chose it because this is really strategic.
Certification audit
Then when you have it you need to plan the audit. You need to agree with the notified body of the date they should come.
Sorry, repeat your question. “What is an audit?”
Oh my god. You have never been audited by a Notified Body. You are new to that game.
Oh,… I remember my first audit. It was really a nightmare. But fortunately I learned from my mistakes.
Ok, Ok, I answer to your question .
An audit is a kind of a meeting with an auditor where you are asked to provide a lot of documents which he or she will be reviewing. The result of this meeting or audit is the deliverance (or not) of the certification to authorize you to market your product in Europe.
Audit readiness
This means for you that you should be more than ready.
Ready is the baseline.
Everyone wants to be ready but strangely, when they pass the audit they receive a lot of non-conformities for stupid things they can have fixed if they were really ready.
Me, I am asking you to be READY.
It means that you’ll implement an Audit Readiness Plan with you team.
Here is another post to read about Audit preparation.
Or easier, come to ask about it on my LinkedIn Group or Facebook Group. Then I can share that with everyone.
If I want to make a quick shortcut, the objective of all this is to always anticipate the question of the auditor and provide the right answer as quick as possible.
With this you should know better than the auditor what is right or wrong in your company. And being able to correct it before.
Imagine that the auditor ask you for the Management Review of 2017 and you hand it to him or her immediately.
Then he asks for the Audit procedure and you hand it to him or her magically like you read on his mind.
He or she should think “They are really good” or even better “They are awesome”.
Finally, you get certified and your SaMD can now be delivered to your customers. I am really proud of you.
Information about SaMD for the US Market (FDA)
If you are looking for information on the USA market, you can have a look at the FDA website where all the information are provided.
You will see that the IMDRF website is also listed, so you may understand that the definition of an SaMD in Europe and in the USA is similar.
The only difference will be the route to market. They are not following the CE mark but you’ll need most likely to register your product through a 510K or PMA.
More investigation should be done to create your Route Plan.
Bonus: QMS software validation
Here we talked mainly about Software as Medical Devices. You should not thing for example that your electronic QMS is part of this category.
If you are developing such software then you should listen to these episodes with Jacob Sjorslev from Simpler QMS
Your turn now
I really enjoyed to show you the journey to put your Software as a Medical Device on the market.
I want to ask you one thing now.
Can you leave me a comment below and tell me the kind of Software that you have (You can say brands if you want some free advertisement) and classify it with the right rule.
This is just for my curiosity.
I teach you but I want also to learn from you. Thanks you very much.
Nice illustration of MDR 2017/745 Classification rule 11
While I was writting this article, I discovered this illustration from be-on-quality GmbH and asked if I can use it on my article.
Medical Device expert. Monir founded Easy Medical Device to help Medical Device companies to place compliant products on the market. He proposes his consulting services so don’t hesitate to contact him at info@easymedicaldevice.com or +41799036836
My objective is to share my knowledge and experience with the community of people working in the Medical Device field.
