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: www.softquest.co.il 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; 

  1. The Scope
  2. Terms and definition
  3. General Requirement for Risk Management
  4. Risk Analysis
  5. Risk Evaluation
  6. Risk Control
  7. Evaluation of Overall Residual Risk Acceptability
  8. Risk Management Report
  9. 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;

  1. Scope
  2. Normative Reference
  3. Terms and definition
  4. General Requirement for Risk Management
  5. Risk Analysis
  6. Risk Evaluation
  7. Risk Control
  8. Evaluation of Overall Residual Risk
  9. Risk Management Review
  10. 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: https://www.fda.gov/medical-devices/medical-device-single-audit-program-mdsap/mdsap-policies-procedures-templates-and-forms

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:  http://portal.anvisa.gov.br/documents/33864/2869776/Medical+Device+Single+Audit+Program+-+Frequently+Asked+Questions/b33795ba-8bbd-45a3-acd2-8c2c5e9976f2?version=1.1


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: https://www.fda.gov/medical-devices/medical-device-single-audit-program-mdsap/mdsap-audit-procedures-and-forms


DEVOPS- Connecting Orcanos to GitHub

May 8th, 2020 Posted by CICD 0 thoughts on “DEVOPS- Connecting Orcanos to GitHub”

We are in a process of transitioning our company towards a full automation development process (CICD), and one of the main things was to start using GIT (GitHub), instead of the SVN (SubVersion).

We were amazed how easy the process was, in terms of connecting Orcanos system to the GitHub

We are using Zapier for the integration, but since the API of the systems is simple, you can do it using webservices.

In this article, we will show the steps of connecting both systems.

Check it out:

Step 1: Add CICD section to your defect and task

Step 2: Define integration ZAP from Orcanos to GitHub, for Defect, and for Task

They both act the same. when adding defect or task in Orcanos, it will be added to GitHub as an Issue

Once issue is added – we will update Orcanos with GitHub issue ID and issue URL

Now, the issue is used for working in Github, and Pull Requests will be linked to it, so you can open the Issue URL from Orcanos

And this is the connecting point from Orcanos to GitHub, that’s it

We are working with Visual Studio, so we use the GitHub issue to connect the Push o Orcanos

You can now customize it to your needs, such as adding tag for defect or task indication, we concatenate the item id from Orcanos to the GitHub issue name




How can you employ the medical device CAPA best practices in your bug tracking?

May 5th, 2020 Posted by ALM 2.0, CAPA, Defect Tracking, Software Lifecycle Management 0 thoughts on “How can you employ the medical device CAPA best practices in your bug tracking?”

How can you apply some of the best practices of a medical device in your non-regulated product? And does it worth the efforts?

In this post, I will describe just a small tweak in your bug form, that will make a huge difference in your bug management and the quality of your product, with just a small tweak of adding “Root Cause” field to your bug form. 


It will make your team THINK. Check it out

What is CAPA

A CAPA stands for  Corrective And Preventive Actions. To make it short – when something bad happens – you are supposed to do some investigation, understand the root cause of what happened, when, why, and come up with a plan of what you need to do in order to fix (Corrective) and to prevent it in the future (Preventive).

Adding Root Cause

Well, there is plenty you can do. But as I said, in this article, I would only discuss a small tweak: Add “Root Cause” field to you bug form


Because it will force your team to THINK. That’s it, no more. And when they think – this is when you start digging gold

Orcanos use case

I will explain using a true use case of Orcanos


Root cause starts with an investigation


We got a timeout message for our dynamic filter. It happened to one of our customers, so you can imagine, it didn’t look too good…as we had to deliver a quick fix.

A bug was reported and fixed, but the root cause field, which is mandatory inOrcanos, said something like “Problem in the query”. So we started an investigation to dig the REAL root cause.


The developer says “It was due to a wrong query to the database”, we ask: WHY? Why did it happen? “Well, It happened because we fixed the filtering mechanism, and the original query didn’t fit”. Oh really? Tell me more. “We have changed the filtering mechanism but didn’t change it in all the places we use this filtering mechanism, such as the dynamic filter”


Because…well, this is a sensitive area, and I was under pressure to deliver and didn’t have the time to go to all places and fix it. It would require lots of testing, and put us in high risk…”
So…Are there more places to check?

“Well…yes…but it only happens when the response has thousands of records…”

So, it will continue to happen, and if I understand correctly, we might have an issue in more places

“..we need to check…”

The decision was NOT GOOD since the problem was not fully resolved

But – the decision was GOOD in terms of reducing risk in a frozen environment and affecting more customers, as this rarely happened


So what could you do better?

“Well, I could fix the bug for immediate resolution, and raise another bug, or task for an overall fix in the next release, I guess…”


It goes and on for more corrective and preventive actions, changing our working instructions, and emphasis these topics on our weekly meetings. 

All because of one investigation. 

So you see, It’s more of a state of mind than a technical stuff


See that sometimes the root cause can reveal much more than just a code mistake. It teaches you about how your team thinks, and what drives them in their decision making, sometimes without seeing the big picture. 

These investigations make them and you to think in a wider scope and become EXCELLENT!

Page 1 of 21
1 2 3 21


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

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