Posts by Rami.Azulay

Why the FDA Increase Software Classification from Moderate LOC to Major LOC?

August 6th, 2020 Posted by Requirements Management Tool 0 thoughts on “Why the FDA Increase Software Classification from Moderate LOC to Major LOC?”

From our advisory board member Mr. Mike Zeevi

Dear all,

These are very trying times and we are trying our best to keep it together. This year, as you can understand, has been quieter than previous years, in terms of updates to the software from a regulatory and quality perspective. I have done my due diligence and have prepared this update, even though it is not as jumping as previous updates.

I am sending an update on software development standards and good practices as I have done in the past.  Hopefully, this will give you new insights on how to relate to some of the issues happening in the regulatory/quality/technical field.

Life is becoming more difficult for the software developer. More recalls; tougher standards.

There are issues that are facts and there are issues that are opinions. Please try to relate to them accordingly.

Due to the corona emergency measures, it may seem that the level of software for submissions to the FDA for software has decreased, but it hasn’t. The FDA is returning more and more projects that were originally classified as Moderate LOC as Major LOC, with all of its implications.

More and more questions are being asked concerning cybersecurity, even though the FDA has not moved forward yet with the new draft guidance for cybersecurity. This is due to the corona wards now transmitting all patient information outside the ward to cut down on the contact with the corona patients.

We have entered a new world where virtual meetings and virtual audits are the norms. You may ask if this makes life easier or harder. The answer is yes.

Please pass this onto all colleagues and compatriots. If there are any questions or comments, please feel free to contact me. If any receiving this indirectly wants to get onto the distribution list, please contact me.

A copy of the attached document is found on our website: under Updates.


GET THE FULL ARTICLE: Software Update 30Jun2020

Get a Demo Today

GDocP (01) – Everything you wanted to know about GDocP

July 18th, 2020 Posted by Requirements Management Tool 0 thoughts on “GDocP (01) – Everything you wanted to know about GDocP”

Meeting FDA Requirements?

We will be addressing documentation as it relates to medical devices, processes, and products. With our articles over the next couple of weeks, you will have an understanding of the right way to adhere to Good Documentation Practices (GDocP) for all things relating to life sciences products such as medical devices, automotive, and substances. You can access our detailed explanation on the subject by following this series. The device/products/substances covered will address consumption for LifeScience in general.

Good Documentation Practice

Some of the areas we will be covering include;

  • Engineering (R&D)
  • Validation
  • Testing
  • Distribution
  • Manufacturing
  • Storage and
  • Holding

With our guidance on the right techniques and tools, you should be able to create documents that are easy to understand, traceable, and consistent.

It is worth noting that the techniques shared in these series are a combination of existing guidelines, legislative regulations from governing organizations, and acceptable industry best practices.

What will you learn in these series?

  1. Know why Good documentation is crucial to FDA regulations or other bodies.
  2. The importance of GDocP and why you should understand it.
  3. Educate members of your team on the right and wrong things regarding documentation.
  4. Apply the knowledge to your daily operations.
  5. Gain confidence in your ability to produce high-quality documents.

Who should learn about GDocP?

Anyone or professional that is responsible for documentation as it pertains to medical products or testing in a manufacturing capacity. 

Areas of focus

We will be focusing on Design Input/Output Requirements Test and Test results as part of GDocP in the following areas;

  • All levels of Engineering Specifications
  • Protocol Generation
  • Legal Factors
  • Costly Errors
  • Protocol Execution
  • Attachments
  • Accountability
  • Variable Data
  • Units of Measurement
  • Calculations or Formulas
  • Rules of Thumbs
  • Oops and Uh-Ohs
  • Expected Results
  • Redline the Changes

At the end of these series, it is our belief that you gain valuable skills in generating good documents for all your medical products, processes, and substances.

ISO 13485:2016 Sec. 8.5.2 – Corrective Action Adverse Effect

July 14th, 2020 Posted by Requirements Management Tool 0 thoughts on “ISO 13485:2016 Sec. 8.5.2 – Corrective Action Adverse Effect”

Quoting ISO 13485:2016

“The organization shall document a procedure to define requirements for: e) verifying that the corrective action does not adversely affect the ability to meet applicable regulatory requirements or the safety and performance of the medical device…”

Orcanos CAPA Corrective Action (CA) offers the ability to refer to each part of the above requirement and to manage each corrective action in respect to the Adverse Effect it may have on the device in terms of:

  1. Regulatory Requirements
  2. Safety
  3. Performance


July 13th, 2020 Posted by Requirements Management Tool 0 thoughts on “SERVICING ACTIVITIES vs. COMPLIANT (ISO 13485 Chapter 7)”

Service activities are similar to Installation or Assembly services. However, some devices or equipment do not require servicing, they are often tagged as disposable devices. Nevertheless, should a device require servicing, then it is imperative that it should be stated in the quality manual.


While disposable devices can be described as an exclusion in the quality manual, devices that require servicing should have clearly stated procedural guidelines on its service activities.


Now, with each servicing, a record needs to be created detailing the nature of the service. Likewise, the installation records need to be updated accordingly. Also, information on tests, calibration, or inspection are to be noted. Very similar to the production of the device for the first time, a Device History Record (DHR) record is being logged for each product serial number. 


Orcanos eQMS system grants you the ability to record both the installation and the production history record of the device, with a strong link to the procedures and processes and supplier qualification processes. 


Standard procedure dictates that there be data testing before and after servicing and the process be documented. Orcanos design control system records the test plan and test results with the ability to report a None Conformity Report (NCR) during the testing state. In so doing, both manufacturers and customers will be able to track the performance of the device prior to the moment of manufacturing or service. Also, it will help identify any prior issues or faults. Finally, it helps to assure all parties that the device was in perfect working condition post-production or servicing.



In the medical device industry, it is possible that manufacturers in the process of servicing a system or device might ignore the role of complaints. While there is nothing wrong with servicing, it is crucial to leave room for complaints to ensure an effective CAPA. Hence, there should be a clear distinction between service systems and complaint systems. Orcanos eQMS comes with a built-in complaint management system that is separated from the service system. Orcanos CAPA management system allows integration natively with the complaint management system as well with the Risk system, all together empower the organization quality management capabilities.


For example, analyzing a diagnostic testing lab equipment. Picture a system that runs a buffer and requires the user to refill it using a buffer bottle. Now, suppose that the service engineer discovers leaks 62% of the time and fix it as part of their service call.


Then, it means that they would have successfully avoided a complaint system that would help track the issue with the product. As a result, there would be no feedback to the CAPA system or manufacturer that would alert them to the flaw in the product.


Major Issue

Such unclear roles in servicing can constitute a major problem in the long term. Therefore, it is important to avoid such issues by defining the roles of servicing and creating a way to have issues beyond servicing reported using the compliant system.

Also, all services and installation should be recorded and updated regularly.


Related Links:

Service Center: Complaint Management ORCANOS QMS – CAPA Management Software
 Customer Service – Orcanos



ISO 14971:2019 ( Medical Device Risk management ) | Detailed explanation Clause by Clause

June 9th, 2020 Posted by Requirements Management Tool 0 thoughts on “ISO 14971:2019 ( Medical Device Risk management ) | Detailed explanation Clause by Clause”

Application of Risk Management to Medical Devices Following ISO 14971:2019 Version

It is imperative to understand the Application of  Risk Management to Medical Devices. Technically, we could say it involves Identifying, Assessing, and Prioritizing risks. In general, it simply means that Risk Management helps us reduce risk.

Before the invention of ISO 14971, there were no standards for device manufacturers to use. Then came the idea of ISO 14971 where manufacturers could apply the principles contained in ISO 14971 list to their medical devices to ensure safety.

The product safety standard couldn’t address all the possible risks in medical devices, hence, the decision by the Standard Development Committee (SDC), to create ISO 14971, the first version of which was published in 2000. In 2007, another version was released.


The Evolution of the ISO 14971 Version

The European Union introduced a harmonized version that combined the two previous versions with new changes for European Device manufacturers. The Harmonized European Version harmonized the three directives related to medical devices namely;

  1. Active Implantable Medical Device Directive.
  2. Medical Devices Directive
  3. In-vitro Diagnostic Medical Device Directive.

As a result, any manufacturer that wants to sell their medical devices in Europe must comply with the EU 2012 harmonized standard. Meanwhile, the rest of the world can use the 2007 ISO 14971 and the 2009 ISO 14971 standards for medical device risk management.

The Importance of ISO 14971 2019 Version

There are a lot of changes that came with the 2007 ISO 14971 version. Similarly, the introduction of ISO 14971 2019 version came with several changes that differ from the 2007 version. Most of the changes between the 2007 and 2019 ISO versions are in the clauses.

The ISO 14971: 2007 had 9 clauses namely; 

  • The Scope
  • Terms and definition
  • General Requirement for Risk Management
  • Risk Analysis, Risk Evaluation
  • Risk Control
  • Evaluation of Overall Residual Risk Acceptability
  • Risk Management Report
  • Production and Post Production Information. 

The Difference between ISO 149721: 2019 and ISO 14972: 2007

We’ll look at the changes adopted in the ISO 14971: 2019, but first we need to list the clauses. The current 2019 version unlike the 2007 version, has 10 clauses namely;

  • Scope, Normative Reference
  • Terms and definition
  • General Requirement for Risk Management
  • Risk Analysis
  • Risk Evaluation
  • Risk Control
  • Evaluation of Overall Residual Risk
  • Risk Management Review
  • Production and Post Production activities.

Note the introduction of a new clause (Normative Reference) to the latest edition in the second step. Also, there changes in the arrangement of the steps between steps 3 and 10. 

Likewise, some keywords changed in the latest version. For example, the Evaluation of Overall Residual Risk Acceptability was changed to the Evaluation of Overall Residual Risk. The Risk Management Report is now Risk Management Review. Lastly, Production and Post Production Information became Production and Post Production Activities. 

These changes might seem insignificant, but most companies have had to revise their documents to accommodate the changes.

There are other standards e.g IEC 62304, IEC 62366- 1, IEC 60601- 1, to mention but a few. The major difference between the ISO 14971 and other standards is their approach to risk management. ISO 14971 provides the fundamental procedures to manage all risks while other standards that attend to only specific risks. The combination of all these standards forms the basics of all medical devices’ risk management.

The Clauses of ISO 14971:2019

Clause 3: Terms and Definitions.

These terms include;

  • Hazard: This refers to the possible source of harm. Identification of all possible hazards is important for your product, be it chemical, mechanical, or any other form.
  • Harm: According to Section 3.3 of ISO 14971: 2019, harm refers to injury or damage to the health of people or damage to property or environment.
  • Hazardous situation: situations in which people, property, or environment are exposed to hazards of any form.
  • Benefit:  Good impact of the use of medical devices on the health of individuals, or a positive impact on patient management or public health.
  • State of Art: According to Section 3.28 of ISO 14971: 2019, it refers to the developed stage of technical capability at a given time as regards products, processes, and services, based on the relevant consolidated findings of science, technology, and experience.
  • Reasonably Foreseeable Misuse: Section 3.15 of ISO 14791: 2019 defines it as the use of a product or system in a way not intended by the manufacturer, but which can result from readily predictable human behavior.
  • Risk: Risk is basically the probability of harm occurring, and the severity of that harm. It is the possibility, whether high or low of any of the aforementioned hazards causing harm to individuals. Once the hazard has been identified, it is then easy to go on with managing the risk.

Clause 4: General Requirement for Risk Management.

The sub-clauses include:

  • Risk Management Process – It involves the overall processes which producers establish, implement, and maintain throughout the lifespan of a medical device.
  • Management Responsibilities – Management responsibilities show the proof of the commitment of management to Management Risk Processes by the provision of adequate resources and qualified persons to carry out the job.
  • Risk Management Plan– It is a document that helps identify risk management activities and helps plan ahead throughout the production cycle. It is a dynamic document and can be updated at will.
  • Risk Management File – Location where manufacturers can find all records and documents relating to risk management. A manufacturer is required to establish and maintain a risk management file which contains evidence of  the following;
  1. Risk management plan intended
  2. Foreseeable misuse
  3. Risk analysis
  4. Risk evaluation
  5. Risk control and more.


Clause 5: Risk Analysis.

Risk Analysis is the use of available information to identify hazards and to estimate the risk – Section 3.19 ISO 14971: 2019. It involves the identification of hazards and hazardous situations, identification of characteristics that are related to safety, and risk estimation.

Clause 6: Risk Evaluation.

After risk estimation comes risk evaluation. It involves clearly identifying what amount of risk is acceptable. A common way of doing this is by the use of Risk Evaluation Matrix. As earlier stated, risk evaluation is basically what risks are acceptable and which ones are not, hence, the working principle of Risk Evaluation Matrix.

It is a chart of the occurrence of risk against the severity. The unacceptable parts are made red, the acceptable ones are marked green, and yellow stands for the middle region where further consideration is probably needed.

Clause 7: Risk Controls.

Section 7.0 of ISO 14971 provides that manufacturers shall determine risk controls that are appropriate for the reduction of risk to the acceptable level. Simply put, it refers to the steps you take once you’ve identified unacceptable risks. 

There are quite many options for Risk control, they include;

  • Inherently safe design and product
  • Protective measures in medical devices
  • Information for safety and training where appropriate.
  • Residual Evaluation Risk: Once risk control measures have been implemented, it is next to evaluate any residual risk using risk management plan criteria as a guide.
  • Risk-Benefit Analysis: In such cases where the evaluated residual risk is not deemed acceptable by the manufacturer, the intended medical use of the device is compared to the residual risk. If the intended use does not outweigh the residual risk, it means the risk is unacceptable. The manufacturer is expected to modify the medical device or its intended use. The device is however good to go if the intended medical benefits outweigh the residual risk.

Clause 8: Evaluation of Overall Residual Risk.

Having evaluated individual residual risks for your medical device, there is the need to also make an overall evaluation of the residual risk of your medical device. The occurrence versus severity chart is also used for this. If it happens that the overall residual risk of your medical device is not acceptable, that is, the overall residual risk is higher than the benefits, the medical device is not fit for sale.

Clause 9: Risk Management Review

This is a summary of all risk management activities stating any risk-benefit analysis and explanation of overall residual risk acceptability. It identifies voids between planned management activities and what was achieved. All identified voids should be filled before proceeding to sell your medical device.

Clause 10: Production and post-production information.

There are quite many ways of going about this, but the best method will be to use the post-market surveillance together with an upgraded risk management plan. Once the device is released, a post-market surveillance plan starts. It basically involves the monitoring of residual risks even when the device is out, to ensure the continued validity of the risk evaluation.


June 9th, 2020 Posted by Requirements Management Tool 0 thoughts on “Orcanos on FEMALE ENTERPRENEURSHIP IN MEDICAL AND HEALTHCARE Event”


Platinum Sponsor of StartupGring Promotion code for Orcanos Clients: sgxrishonorcanos

✅ Empower your Audit Readiness
✅ Strong collaborative workspace
✅ Proactive Regulation Compliance Alert
✅ 72 hours Onboard Package

Free eBook – The ORCANOS Story

June 3rd, 2020 Posted by ALM 2.0 0 thoughts on “Free eBook – The ORCANOS Story”

Coronavirus is a deadly and highly contagious disease that spreads
rapidly. Its rate of infection has impacted various business industries
in unexpected ways. There is no cure for the disease yet. Therefore, most
businesses around the world have made the decision to shut down to
help reduce the rate of infection. Also, employees are being encouraged
to practice social distancing by working from home.
However, essential workers such as health care professionals, grocery
store workers, and more still have to go to work. The impact of COVID-19
on both small and large businesses is projected to be huge as the
pandemic does not seem to be ending anytime soon. It would take quite
a while for several businesses to recover from such a hit.
Tech and software industries like the software vendors industry have not
been spared of the chaos. Although the effect is to a lesser degree
compared to other industries especially if your solution is on the cloud
provided as a SAAS platform. All Internet Software companies, Service
Providers, and Information Technology Services are not fully affected by
the restrictions that have been imposed on other business sectors.


Download the full story Free eBook – The ORCANOS Story Rev 05


May 16th, 2020 Posted by Requirements Management Tool 0 thoughts on “BENEFITS OF THE ALL IN ONE MDSAP AUDIT MODEL (02.03)”

According to the FDA, the MDSAP pilot audit was developed to cover existing requirements from the regulatory authorities participating in the MDSAP Pilot in order to facilitate an all in one audit.

Apart from the existing requirements by the ISO13485: 2016 and the medical device regulations from the participating regulatory authorities the program does not include any further requirements.

The audit incorporates the following

  • ISO 13485: 2016 – Medical devices Quality management systems; Requirements for regulatory purposes
  • Quality System Regulation (21 CFR Part 820)
  • Brazillian Good Manufacturing Practices (RDC ANVISA 16/2013)
  • Licensing, Registration, Advisory notices as well as other specific requirements as medical device regulatory authorities participating in the MDSAP pilot program.


In the United States, the U.S. Food and Drug Administration’s Center for Devices and Radiological Health allow the use of the MDSAP Pilot report as a suitable alternative for the FDA routine inspections.

Furthermore, the certification documents issued by the auditing organization communicate compliance with applicable US regulations which may provide a marketing advantage.


The purpose of MDSAP and its Pilot Program goals are parallel to each other such as

  1. To improve medical device safety and oversight with the help of various international bodies across all borders.
  2. To provide a single audit program that provides confidence to international regulators
  3. To effectively reduce the regulatory burden on the medical device industry by enabling Government regulatory authorities to focus on problematic manufacturers. Thus, allowing notified bodies to carry out inspections on their behalf
  4. To promote a more efficient and less burdensome regulatory oversight of manufacturers medical device quality management systems
  5. To endorse a proper and effective utilization of regulatory resources through mutual acceptance and division of labor among regulators
  6. Finally, to encourage better global alignment of regulatory approaches and technical requirements based on agreed standards and best practices.



All the necessary Information about the MDSAP Pilot Audit Model is available online. Other documents specific to the MDSAP Pilot can be easily accessed on the FDA website. The government documents N3, N4, N5, N6, and N11 which specify the requirements for regulatory authorities, the auditing organizations, and also serve as the basis for the MDSAP pilot are all accessible on the IMDRF website.



There are several online resources provided by the FDA that provide more information about the MDSAP Pilot Program and this include

  • Pilot Program Announcements
  • Program Announcements
  • MDSAP Audit Procedures and FORMS
  • Eligible Auditing Organization
  • Follow up online to learn more


All policies, templates, procedures, and forms for MDSAP can be found online at the FDA’s website at both of the following locations below

Visit FDA web site:

MDSAP, FDA and ANSA Question and Answer Site

The MDSAP Question and Answer Information is already integrated into the course but for future references, you can check out the link below for more information

Here is the link:


The following documents below are used for the actual audit and can be accessed at the FDA site online

Here is the link to the FDA site online:


Why Design Control Is Important For Medical Devices?

April 11th, 2020 Posted by Requirements Management Tool 0 thoughts on “Why Design Control Is Important For Medical Devices?”


Looking to expand your knowledge of medical devices? Then, this white paper is for you to read. During this paper, you will learn the primary concepts of design control as well as the necessary things needed in order to be successful in product development of medical devices such as –

  • Intended use
  • User needs
  • Design input
  • Design verification
  • Design validation and
  • Design transfer


Goals You Can Achieve

Listed below are the goals to be achieved with this short course

  1. To get a basic knowledge of design control for medical devices and why it is important.
  2. To figure out more specifically how to implement design control in the Orcanos ALM system for design control. Orcanos offers on vas knowledge for the Medical Device and Automotive industry at the same time. This could be useful for your job or career also offers a full eQMS cloud base platform for complimentary quality procedures and processes used by regulated industries such as Medical Device, Automotive which is quite similar to this one but much comprehensive with more in-depth requirements.

By the end of the paper, you would be equipped with knowledge that might prove to be very useful with Auditors. 

What is Design Control?

Design control is a quality system regulation that covers requirements on how to carry out product development of a medical device or basically the name of chapter 21 of CFR 820.

Understanding design control requirements is necessary especially when selling to the United States because design control requirements are mandatory for medical devices in the US. It goes as much to say that no design control also means no market access.

The same requirements also apply if you’re selling to the European Union but instead they can be found in chapter 7.3 of the EN 1S0 13485 standard

Why are design controls important?

Here are 2 good reasons why you should care about design control –

1. Regulatory Requirements

Conforming to design control requirements is a regulatory requirement and working according to these requirements is an effective way of maintaining the production of safe products that will satisfy your customer’s needs.

2. Best practices

The design control requirements also represent best practices in developing new products and taking a look at companies from other industries where design control requirements are not necessary, you would still find them abiding by these principles anyway because they recognize the values behind it.

Learning about design control is not only about complying with certain requirements in order to gain access to the US and European Markets. Its major purpose is to help develop successfully safe products that also meet your customer’s needs.

It’s important to understand the industry language of whatever industry you work in and the same also applies to Medical device product development. If you happen to work in other product development industries before joining medical devices you’ll find that many concepts are the same but there are 2 things that are essentially different. First is that there are different names and terms for things and secondly the obsession of Risk management and Safety.

Because of that unique link between the design control and RISK not many systems allow managing both in the same system. Orcanos provides a unique ALL IN ONE platform over the cloud that interconnects these elements as creating a collaborative environment to streamline data from design control to risk and vis versa.

In this short paper, we would be bringing some of the popular keywords that are used very often to your attention. Getting to know the medical device terminology will prove very useful especially with understanding your colleagues and your company’s quality procedures.

If you want to learn more about the things we will be sharing information on our blog discussing on to 

Principles of Medical Device Product Development

Intended use/Intended purpose

Intended use is a short but high-level description of the user profile, what indications the device is intended for, patient groups and other important conditions of use as intended by the product manufacturers.

This is a term that you should have defined quite early at the beginning of a project. For better understanding, here is an example of the intended use for a thermometer – which is so commonly used nowadays during the COVID-19. 

ThermoScan Thermometer

The Thermoscan thermometer is designed for intermittent measurement and monitoring of human body temperature for both adults and children. It is intended for household use only.

It is important to get the intended use of a product correctly because in nations like the US, whether the product will be cleared under a 510k or require pre-market approval depends on the Intended use.

A simple way of coming up with your intended use is to answer important questions like the 5W technic.

  • Who
  • Whom
  • What
  • Where
  • When

For instance, who would be using the device and on whom for, what where and when is the device used. The trick is to answer these questions using simple sentences and you’ve successfully defined your intended use.

Sometimes, not all intended uses will be fully defined and properly answered but if you can manage to answer them all then you should be able to properly describe what your intended use should be like.


User needs

User needs are another important concept you should be defining at the beginning of the project. As the name implies your user needs should simply define the needs of the users and they must be in line with the intended use. An example of user needs is that the system should be portable

Design Input

These are an abstract technical requirement that realizes the user needs when implemented in the design. The user needs is what is being translated into design input.

For instance, if the user needs to require that a system should be portable and in this case, portable can mean a lot of different sizes for the user. We can decide that the weight of the system should not be more than 10kg and another person might choose to go with another weight that might also work out for this particular case.

At the end of the day, what we try to do is to come up with abstract requirements that would work best for the users according to the user needs. Getting the translation for user needs into the right technical requirements is very important for consumer acceptance as well as the overall success of your product.

There is no part of the regulatory requirements that indicates who should come up with the user needs and design inputs but most times the people who shoulder the responsibility of defining user needs are usually found in Management or Product Management and Marketing. Orcanos system supports all types of design inputs and if needed more types the enterprise edition allow you to add more requirements as needed.

If the design input is technical in nature they are usually established by the engineering department and would feature engineering language.

In some cases, the design inputs may act as the mitigation for the RISK introduce by the user requirements or in other cases they can act as the source for RISK as well. This all depends on the size of the organization or the complexity of the device.

Design Verification

It’s a general principle in Product Development that after designing a product, you have to check that the design or product you came up with actually correlates with the requirements you defined at the beginning of the project. For the Medical Device Industry, this process is an important regulatory requirement termed Design Verification

Design verification confirms that design output meets design input requirements. In this scenario, the design input was that the device weight should not be more than 10kg and to verify that this requirement adhered to, the device would be placed on a calibrated scale and weighed accordingly.

There a lot of methods and processes that can be used for verification and demonstrating that your design output has met the requirements of your design input and in most cases, the methods or process you use is up to you to decide on.

After confirming that the product meets the necessary technical requirements, you also have to check that the device is in due accordance with the intended use and user needs.

Design Validation

In real-life settings, sometimes a product can be 100% technically accurate but still very much useless. To avoid that the device has to undergo a design validation process.

Design Validation is another important regulatory requirement and it must be done by testing your device or design in a real or simulated environment. According to the requirements, you also have to use production units or equivalent devices during the process.

Still using the example mentioned above – with a product that is required to be portable you could let a few users carry the device for short while. Using their responses you can thereby conclude if the product is portable or not.

Although, it’s not every time that Design Validation is that simple because sometimes you cannot confirm that the intended use and user needs have been met without carrying out a clinical investigation or use on real human subjects

Competent Authorities 

There are various regulatory bodies across the world that ensures that medical devices companies are doing things the way they should be done. For instance, each country in the EU has a supervising government body for medical devices. In the United Kingdom that would be the Medicines and Healthcare Products Regulatory Agency (MHRA). In Sweden and Denmark we have the Medical Products Agency and the Danish Medicines Agency respectively. We also have the Food and Drug Administration (FDA) for the USA. In general, we call these organizations Competent Authorities.

Notified Bodies

In most cases when you sell to the European Union, you would never have to contact or meet with the competent authorities except something goes terribly wrong with the medical devices. Because the auditing of medical device manufacturers, for most manufacturers selling to the European Union is done by companies that have earned the status of being notified bodies.

The notified body assigned to you will come to audit you periodically throughout the year depending on your product and audit scheme and since you are their customer you would be charged a fee for these audits.

You will be communicating with the notified bodies and the FDA to receive your market clearance and approval. For countries In the EU, that would be receiving the CE mark but for countries in the US, you would receive an FDA clearance or approval depending on which classification your product has and which market access route you have taken.

Next, we would be looking at how this design control terminologies are utilized in a product development process.

Products Development Proccess 

The following steps are involved in the products development process –


Starting a project formally is referred to as Initiation. Initiation should or could be a fairly short phase involving just a few days to make the decision, to begin with. The decision may also be well documented in a project charter.

From a regulatory point of view, Initiation does not necessarily require any formal requirements but most times some Auditors or Inspectors might ask you when the project actually started and the initiation and signing of a project charter would be a great way to show just that.



Some people might think that it’s hard to get the planning started or maybe there is still too much uncertainty to create a relevant plan. This is where it might be very wise to consider running a pre-study before you start planning.

There are many different names for this phase. It could also be called a feasibility study or concept study but whatever the name is its purpose is to remove doubts by decreasing uncertainty to a level where it is appropriate to start the project under design control.

Good piece advice is to not wait too long before getting the planning started this is a common mistake at this phase of the project.

There are 4 questions you’ll need to ask yourself during the planning phase which are what, when, who and how much.

The first question to ask yourself when you start planning is what? What is the purpose of this project or what objectives are you trying to obtain? The answer to this should contain the intended use, user needs and the design input that we’ve mentioned previously during the course.

In project management terminology this can be likened to defining the scope of the project as well as the deliverables and the product requirements.

People in your organization would usually expect the project manager to come up with who will be doing the work and when they will be doing the work.  In many cases, the latter would be documented in a Gantt chart. This is another tool Orcanos provide you to allow you to control and govern the project

Traditionally, the planning we have talked about so far would be carried out as part of a typical project management but from a design control point of view it is seen as a major requirement and is referred to as design planning.

Lastly you should define how much the project would cost. The FDA and other notified bodies do not necessarily have any involvement with how much your projects should cost which is why having a budget is not a regulatory requirement as long as the devices meet up with the proper requirement in terms of safety and efficacy

Don’t worry if you’re not familiar with the terms we’ve discussed from your own processes and procedures. Most times different companies use different names. As a general approach we try as much as possible to stick to terms from standard and norms or what is most commonly used by the industry. 

Execution and Design

The next step after planning is execution and design and it involves 3 phases

  • Design
  • Design verification
  • Design Transfer


If you ask anyone the easiest part of the project to relate with is design. It is quite simply the phase that is focused on creating the design and it’s usually the first thing to do in the execution phase of a product development project

For example design would be to design parts and select components for a mechanical device and for electronics it would be creating schematics, making circuit board layouts and selecting components. Design for software would mean to create the code. For a complex system design would mean to do everything above mentioned as well as integrating them as a system.

Design verification

A device should be designed based on the design input that was defined during the planning phase and when the product has been designed you would have to show that what you did meet with the requirements of the design inputs and this process is known as design verification.

During Design Verification you should be able to provide objective evidence that your design outputs which the design you have created is in line with the design inputs or otherwise known as the product requirements. A good way to prove this is to test the device.

You may do design verification on early prototypes based on a regulatory point of view but you have to be wary because it’s possible that the products you create during your first production might be different from your early prototypes.

In most cases, the early prototypes from the engineering department perform better when compared to the products that eventually come out of the first production. This usually happens because you had your best engineers build and tweak the first prototypes until they did what they were created to do and when these engineers are not around during production you might end up with different results at the end of the day. Orcanos will provide you with an eDHR system that will make sure that your Design inputs are tested during the QC of your production.

This brings us to another important process which is creating the capability to manufacture the device in production. 

Design Transfer

There should be a part of your plan dedicated to setting up production for your medical device. It is not just good advice but it’s also a regulatory requirement and that important element of product realization should not be left to chance. This process is usually referred to as design transfer

Design transfer comprises of areas such as

Some companies might refer to design transfer and reserve as a ramp-up for production after regulatory approvals and there is nothing wrong with that since there is no rule that requires you to call certain phases by certain names. However, it does help to use commonly used names because it facilitate easy communication with regulatory organizations such as your notified body and the FDA.

Design Validation

After proving that your device is technically alright with the design verification and setting up production the next step is to of course validate the design.

The design validation should confirm that user needs have been met and that your device works like it is intended to. Please do not confuse design validation with process validation or usability testing because they are not the same thing.


It’s possible for you to close down the project if you are not the project manager or not involved in clinical investigations or also regulatory submissions. This would be perceived as an administrative closure of the project involving nothing required from a regulatory point of view.

Clinical investigation

It’s a very good idea to learn about what worked and what didn’t work in your project. You can spend a few days ruminating on what you’ve learned and when you are done you could either CE mark the device or proceed to carry out a clinical investigation and then CE mark the device but for the US market that would be seeking for an FDA clearance or approval via a premarket approval process or pre-market notification.

Some companies use a phase call Post Marketing Survalinace (PMS) to understand better how the product performs. This phase means the collection of complaints from the customers and analysis of theses complaints and performs preventive measures. Part of the Orcanos eQMS solution includes a complete complaint management system to comply with the PMS requirements guidelines, given by the ISO 13485 Sec. 8.2.


Finally, you’re at the end of the project and you’ve handed over the necessary responsibilities to the production department. You should still work with design control so if there is a need for any change during this phase you can implement change control on the product. The Engineering Change Order (Notification) called ECO/ECN process involves the ability to identify each change and to asses each change against the potential RISK it may introduce to the patient/user/operator/doctor. Orcanos includes a complete ECO system that allows the manufacture to execute the ECO procedure with 100% accuracy. 

You might also be need to update risk management file and clinical evaluation report as well as other relevant documents as you learn from your products on the market.

We have introduced you to a whole lot of design control requirements and principles together with the project process and we hope that by now you have a better understanding on the basic concepts of design control

If you need templates for more inspiration or knowledge on design control, check out our free evaluation system which includes templates on product development at or you can also consider taking the time to meet with us using our online scheduling link.

We also offer online training, onboarding courses, public/zoom classroom as well as in-house training on design control, risk management design control, and project management for medical devices.


March 31st, 2020 Posted by Requirements Management Tool 0 thoughts on “INTRODUCTION TO MDSAP (02 Continued)”

MDSAP Pilot Program Participating Countries

Representatives from the following international coalition of countries participated as pilot developers in the MDSAP pilot program:

  • The Australian Therapeutic Goods Administration  (TGA)
  • Brazil’s Agencia Nacional de Vigilancia Sanitaria (ANVISA)
  • Health Canada
  • U.S Food and Drug Administration (FDA) and
  • Japan

International Regulatory Authorities Participation

Every Regulatory Authority that participated in the MDSAP pilot program were considered to be equal partners. The results obtained from the final MDSAP pilot report are based on data accumulated over the course of the three-year pilot. It is expected that more Regulatory Authorities will participate in MDSAP and become active participants in either the pilot program or the implemented MDSAP program.

The observer status and role of European Union were discussed. However, the EU’S participation was declined and this could have been ascribed to the number of member  countries in the Union.

Observers of the MDSAP Pilot Program

MDSAPJapan’s Ministry of Health, Labour and Welfare (MHLW) together with the Pharmaceutical and Medical Devices Agency (PMDA) were observers to the Regulatory Authority Council (RAC) and Subject Matter Expert (SME) in 2013.

The World Health Organisation (WHO) was also an observer to the SME Working Group whereas the European Union participated as observer Status in 2014.

For IVDs pre-clearance process, WHO serves as a member of the IMDRF-MDSAP working group and as an observer to the MDSAP. WHO has shown a willingness to adapt and inculcate MDSAP processes to a certain extent in their pre-qualification program.

MDSAP – Roles of Participants and Observers

MDSAPMDSAP roles involve both participants and observers. Below are their roles explained in detail.


  • The Regulatory Authority participants provide the resources to support the development,  implementation, maintenance and expansion of MDSAP.
  • The Regulatory Authority participates actively in the process of recognizing, monitoring and re-recognizing Auditing Organizations under the framework of the IMDRF and MDSAP.
  • The participating Regulatory Authorities have committed to the use of MDSAP deliverables during the pilot in order to assess program success.
  • Each Regulatory Authority participant is also represented by two senior level managers or the MDSAP Regulatory Authority Council  (RAC) which is the MDSAP’s governing board.


  • A Regulatory Authority who is an observer may attend MDSAP, SME, WG meetings, assessments and other activities but are not to utilize MDSAP program deliverables to replace or supplement it’s regulatory scheme deliverables of let portions of these deliverables.
  • The observers are represented on the MDSAP RAC by one senior level manager.

Pilot MDSAP “Criteria for Success”

The MDSAP Subject Matter Experts Working Group came up with a plan to gather evidence for a “Proof of Concept” of the MDSAP pilot.

There are 8 performance indicators to determine the success of  the pilot. The criteria for success based upon audit reports and nonconformities. These criteria use a method for data collection, sampling method of analysis and Targets which were defined for each indicator.

More information on these criteria can be seen in MDSAP P0007 Proof of Concept for MDSAP pilot document.

How the MDSAP Pilot Audit was Conducted

MDSAP Pilot audit will be conducted by an Auditing Organization according to the FDA. This will be done through the use of  applicable documents developed by the participating Regulatory Authorities for the implementation of the program pilot.

The following policies and procedure were detailed by the FDA on their website:

  • Auditors must follow the sequence of tasks specified in the audit model- MDSAP AU P0002 in order to ensure consistency across auditor teams and auditing organizations.
  • The auditing organization determines the audit duration based on planned audit tasks – MDSAP AU P0008 in order to ensure consistency across auditing organizations.
  • The audit duration will not exceed the accumulated time of multiple audits and inspections they would undergo if the participating Regulatory Authority perform their inspections according to their governing policies.
  • The auditing organization writes an audit report for each audited site using a standard fillable template specifically designed for medical device regulatory audits.
  • Nonconformities identified during an audit are graded on a scale from 1 (least critical) to 5 (most critical) according to explicit criteria – GHTF/SG3/N19.
  • High-grade nonconformities may trigger the performance of an unannounced audit.
  • The manufacturer provides, and the auditing organization reviews, remediation plans and evidence of implementation of these plans according to a specified timeline- MDSAP AU P0027.
  • Auditing organizations will share the audit outcomes with the participating Regulatory Authorities to support their pre-market and post-market programs.
  • Upon successful certification audits, auditing organizations issue MDSAP – SPECIFIC certification documents stating compliance to MDSAP audit criteria – MDSAP AU P0026

MDSAP Pilot Grading System

The MDSAP grading system eliminates the classification of major and minor conformities that the IS auditing system instituted. With the MDSAP grading system, there are no longer majors and minors concerning nonconformities. Instead, the MDSAP grading system uses a 5-point grading scale which ranges from 1 (LEAST critical) to 5 (MOST critical). For more information you can access the GHTF/SG3/N19:2012 (Review the last two pages).

MDSAP Pilot: Mid-point Status Report

This represents was released in August, 2015. It revealed that 45 manufacturers had registered to participate as of July of 2015.

The FDA faced challenges in trying to get companies that dealt in medical devices to sign on to MDSAP. These challenges could have been due to the fact that there were only few qualified auditing organizations available to carry out the audit.

The FDA states in the report that “As more Auditing Organizations become authorized to conduct MDSAP audits, a continuation of the positive slope is anticipated. It is too early to project whether target goals will be met”.

Under MDSAP, only organizations recognized by the Canadian Medical Devices Conformity Assessment System (CMDCAS) are authorized to carry out audits.  There were 13 CMDCAS registrars identified as eligible to participate in the MDSAP pilot and only 6 organizations had signed up and undergone application review and assessments as at July, 2015. By the conclusion of the MDSAP pilot, all 13 organizations had completed these assessments.

Another factor to participation may have been that if an organization had a notified body that was not approved for MDSAP audits, they would need to have another assessment in addition to the regular ISO 13485 audit.

The proof of concept criteria goal was 10% participation level which translates to about 330 manufacturing companies for the MDSAP pilot.

Who Performs the MDSAP audit?

Only approved organizations could apply during the MDSAP pilot. In total, there were only 11 of them. However, at the end of the pilot application, other organizations were being accepted for the consideration for the approval to perform MDSAP audits.

An organization must submit an application to the MDSAP and be approved in order to be recognized by the program as an approved auditor.

MDSAP Pilot: List of Auditing Organization Participants

The following auditing organizations participated in the MDSAP pilot:

  • bsi group America Inc.
  • DEKRA Certification bv
  • DQS
  • Interested testing services NA Inc.
  • Laboratoire National De Métrologie et D’essais GMED Certification division
  • Lloyds Register Quality Assurance Inc.
  • National Standards Authority of Ireland (NSAI)
  • QMI SAI Canada Limited
  • TUV Rheinland of North America Inc.
  • TUV SUD America Inc.
  • UL Medical and regulatory services

Expected Improvements from Implementing MDSAP Pilot Program Audit Model

The MDSAP Pilot was expected to improve the predictability of audit outcomes through:

  • The use of standard MDSAP audit model by multiple international regulatory authorities and auditing organizations
  • Enhanced auditing organization recognition criteria
  • Monitoring of Auditing Organizations by the participating Regulatory Authorities
  • The grading of any nonconformity using objective criteria to characterize the significance of the finding
  • The reporting of the audit outcomes using a standard report template.
Page 1 of 15
1 2 3 15


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use