Posts in ALM 2.0

cGMP – Design and Development Master Validation Plan (10)

July 15th, 2019 Posted by Requirements Management Tool, Test Management, Validation and Verification 0 thoughts on “cGMP – Design and Development Master Validation Plan (10)”

People in the medical device industry are often wary of the term validation even though they shouldn’t. Validation is using objective evidence and experiment to ensure that a set of requirements are met when testing for product or service usage. Furthermore, as it pertains to device validation. The objective is to match the specifications with user needs and application. Therefore, validation is proof that using a specific process to manufacture a device will meet both device requirement and user demands.

Validation is the building block for verifying the quality of a product. As a result, the product that is tested during validation must represent the final product. According to ISO 13485, companies must keep a record of the product they use during validation.

Validation MVP

In the same way that the design control process starts with a plan, validation must take the same approach.  The plan is often extensive, covering several areas earning the name Validation Master Plan (VMP) or Master Validation Plan (MVP). It is best to always start the validation plan early in the design process. The plan should be able to pinpoint what will help satisfy the criteria like;

  • Methodologies
  • Performance properties
  • Validation activities

Likewise, there should be a review of the validation plan to avoid risk and deficiencies.

“The First Article”

The first article is the common name given to the first set of products. They are either serialized batch or initial batch (Validation batch). In some cases, validation reports help to document the properties of the first articles. Also, there could be a separate first article report. Forgetting to include labeling and packaging as part of the validation process is a common oversight.

It is crucial that companies include packing in their validation plan. Its effect of product performance is enormous and difficult to measure.  Some packaging can give off electrostatic charge or cause the material to leach into a sterile product. Therefore, testing the packaging can help prevent such occurrences. Similarly, the validation plan should include labels. Environmental conditions can cause labels to fail, leaving the product bare and unbranded.

Inclusion of clinal trials in the product validation is optional and depends on the type of product. Nevertheless, there should be some form of clinal evaluation just in case. Also, validation should account for the worst possible scenarios using simulations that mimic the conditions that the product will face. Some possible simulations can test for the following;

  • Vibration and shock
  • Temperature
  • Humidity
  • Other tests will account for either transportation or storage of the product.

Finally, validation should take into account the following customers/users;

  • Operators
  • Patients
  • Caregivers (nurses/doctors)
  • Other relevant parties


Orcanos Master Validation Plan

Related Links

CAPA: Corrective and Preventive Actions Introduction Principles – Chapter I

July 7th, 2019 Posted by Requirements Management Tool 0 thoughts on “CAPA: Corrective and Preventive Actions Introduction Principles – Chapter I”

Corrective and Preventive Action (CAPA) is a way to improve the company’s processes. They are a series of actions that eliminate unforeseen events and causes of non-conformities. Likewise, CAPA, as a concept falls under several ISO business standards and Good Manufacturing Practice (cGMP).  The primary focus of CAPA is focusing on the root causes of specified problems and risks. In so doing, it can help ensure that they won’t be a need for either corrective action or preventive action in the future. This article aims to help you understand the CAPA process within a regulated environment.


The outline on the subject of CAPA is as follows;

  •         Background
  •         The current State of CAPA
  •         Process Requirement
  •         Process Analysis
  •         The CAPA status review
  •         Conclusion


Two major forces drive the CAPA system. In the US, there is the Food and Drug Administration, the federal regulations, Title 21 Part 820 Subpart J, and CAPA Section 820.100. Meanwhile, companies in the EU that accept the ISO 13485 standard for the quality system there is the Section 8.5.2 corrective action and Section 8.5.3 preventive action. It is worth mentioning that 820 will be known as 21 CFR 820, and 13485 will be EN ISO 13285:2016. Also, there is not of a difference between the old 13485 standards of 2003 and the updated version of 2013 but there are some changes on the 2016 edition when it comes to CAPA requirement.

It is a requirement for both the US FDA and ISO 13485 that CAPA procedures be documented. In the descriptions for CAPA in both organizations, they both address non-conformities.

Regulatory Confirmation

The eligibility criteria for a CAPA system mandate that a situation of non-conformance or a risk of having it. The common suspects for non-conformance issues are either components, products or something physical. However, processes are also suspect despite being less obvious. Regulations often demand that organizations follow specific processes when collecting or analyzing artifacts. Non-conformities are bound to happen when processes are ignored, and there is no collection of artifacts.

CAPA has two distinct components, namely, corrective action and preventive action. Corrective action is used to address systemic non-conformities when they occur. Meanwhile, preventive actions help to address the risk of non-conformities that are likely to happen. In that sense, an electronic system such as Orcanos must let you conduct traceability to CA/PA activities as well to RISK and its mitigation.  

Image1: Orcanos Traceability from/to CAPA

Only About Compliance?

There are pivotal debates regarding the CAPA system. There is an argument that if there is a systemic non-conformity, then action should be taken to identify why and take action to fix and prevent the occurrence in the future. On the other hand, companies find preventive actions problematic. It is not unusual that companies take precautionary steps frequently in the form of reviews, prototypes and much more. However, rarely do they run the steps through the preventive action process.

Despite CAPA and DR (Design Review) and report topping the list, it is difficult to ascertain the safety and effectiveness of products considering the high rates of recalls. A non-scientific approach to the various findings reveals that there is a lack of understanding when it comes to the CAPA approach. The result leads to a lack of implementation. For example, stating that all CAPA will be closed in 60 days in the CAPA Standard  Operating Procedure (SOP) is wrong. The action further demonstrates a lack of understanding of the CAPA process. Inspectors are left with no choice other than issuing findings to processes that they can’t implement or follow.

Therefore, this article will be highlighting realistic ways to approach the CAPA process. The hope is that it will reduce any form of self-damage when it comes to findings and equip you with tools that will guide the regulatory compliance of your business. Eventually helping you making a choice to move onto some electronic form of system to manage the CAPA complete process.

The Basics of Corrective Action

Corrective Action is the first section of the CAPA. Identification of non-conformities tends to trigger corrective action. Although, the language in 820 when addressing CA is cause for confusion as it stipulates action to eliminate reoccurrence. There will be clarity on the subject further down the line.

The Basics of Preventive Action

Preventive Action (PA) represents the other half of CAPA. It becomes actionable in situations where there is a risk for non-conformities, and no steps are in place to mitigate such risks. IT worth mentioning that while in the 13485 standards, there is a distinction between CA and PA. While in 820, there is no such distinction when it comes to CAPA. 

We stated that PA is a frequent feature as part of a company’s project risk activity. The activities often include design and review for manufacturing, preventive maintenance and much more. However, the challenge is identifying when to apply preventive action.

Key Concept

The inconsistent use of terminologies is to blame for the problems in the findings of the CAPA system. To correct this notion, we will be using some easy to grasp terminologies in the absence of standard definitions.

  • Corrections: They are actions taken to resolve problems like replacing a faulty capacitor in a circuit board. Another example is fixing a software bug that alters the user’s input.
  • Corrective Actions: Actions that helps ensure that a problem will no longer occur. For example, changing your capacitor supplier cause they supply faulty resistors to a more reliable supplier. Alternative, training a programmer on a concept that they made an error while working.
  • Preventive Actions: Actions that will stop a problem from happening. An example is reviewing a capacitor’s rating before use to estimate the likelihood of fault. Alternatively, set up a coding standard that programmers can use to review their code to prevent problems.

Systemic Issues

It would not be efficient to flood the CAPA system with every issue. As an alternative, only system issues should be in the CAPA system. Now, the question becomes, what is a systemic issue? In simple terms, it refers to problems that will keep happening without any intervention. System issues can manifest in the following ways;

  • Quality: Missing procedures in the quality process.
  • Product: Failure that keeps rerepeating.
  • Manufacturing: Out tolerance results that don’t stop.
  • Process: Missing steps or lack of actionable steps.

Non-Systemic Issues

By describing non-systemic issues, we better understand the difference between it and systemic issues. Non-systemic issues are problems that are likely to happen once or possess low reoccurrence probability. When dealing with processes, fallouts are not unusual. Therefore, having fallout that is within the limits of the process makes the problem non-systemic. Checking trends and frequency of a problem occurring is the best way of determining if it is non-systemic. However, if you have a non-systemic and non-conformity problem, the action is required.

Some of the best practices will involve checking the trend of all non-conformities, and assessing non-conformities to determine the disposition. Orcanos eQMS system includes a Non-Conformities eForm that will allow you to report and measure your NCR. 

Systemic Issues Product Examples

Below are a few examples that showcase system issues in products.

  1. Should the door be open, an infusion pump will not prevent free flow. The free flow is a systemic issue as the door opening with a set installation will not stop people from seeing the patient.
  2. Cross-contamination of duodenal scopes is responsible for a spate of infections. The reason is that the scopes were not cleaned properly to prevent infection. The problem might have fallen under non-systemic issues if it happened just once. However, the frequent rate at which the infection keeps occurring makes it a systemic issue.
  3. After several testing, making parts that do not match their corresponding mating part as per specification. The rate at which this error occurs and the fact that it surpasses the process limit makes the error systemic.

Systemic Issues Process Example

Problems can come from other factors like processes rather than the product.

  1. When an audit reveals that the quality system failed to incorporate a CAPA requirement. For example, a means of assessing the effectiveness of corrective action. The problem becomes systemic if the process is already reviewed, approved and documented.
  2. An FDA inspection revealing that a company does not keep a record of customer complaints and then issues them a 483. The problem is systemic if the people responsible for taking the call do not realize that all customer related calls should be recorded.

On our upcoming post about CAPA, we will give more tools and tips about how to improve the handling of the CAPA process and be more effective.

cGMP – Design & Development Review Principles

July 1st, 2019 Posted by Requirements Management Tool 0 thoughts on “cGMP – Design & Development Review Principles”

It is quite essential to have a formal design review process. When designs are made or put in place, it is of utmost importance that they are reviewed. A formal review process will help you critically analyze a design in its entirety.

Design Review

This consists of a documented evaluation of the design. It is a comprehensive and also a very systematic process. A design review possesses the data gotten after the proper examination of a design. In a nutshell, it seeks to also carefully evaluate the adequacy and/or capabilities of the design requirements.

One of the most important reasons why a design review is a must is because it will help to identify the problems in the design. While that is really a plus, it is not its only function as it can also help to implement corrective actions to said problems. Design reviews are usually enforced at a more specific/critical stage of the design. However, there are a few other instances that may warrant a design review.

Uses of a Design Review.

The necessity of a design review cannot be overemphasized and this is because it can be used to achieve the following;

  1. Project Progress – In order to formally determine the progress level of a design project, you will need to conduct a design review.
  2. Provide Feedback – A design review helps to provide a comprehensive analysis of the design. This feedback can be used to generate useful data during the design process.
  3. Notification of Emerging Problems – A design review is still your best bet in discovering problems that may arise in a design project. It serves as a check and balance system during the design process.

Orcanos Design Review System

Factors that Influence the Phases of a Design Review.

There are two major things that directly influence the number of phases in a design review. They include;

  1. The Organization – The organization responsible for the design would usually have their own unique parameters or systems in place when making a design. Depending on the bottlenecks in the design process as per the organization’s procedures, a design may have a single or multiple phases in its design review.
  2. The Complexity of the Product – For a simple product with minimal interfaces, it is possible to have a design review with only a single phase. However, if the product is a complex one, it follows that it would generate more than one phase due to its numerous interfaces and sub-systems.

Design Freeze.

This simply refers to a stage in the design review process where design cannot accommodate any more changes. However, this stage will only allow changes if a formal change is made to the design.

Orcanos Freezing Mechisim

Collection of Reviews.

A diverse number of reviewers are typically required when conducting a design review. When orchestrating a review, it should be a collective one where the reviewers are both in-house and external. This would allow for an unbiased examination and final judgment on the design. These reviewers should be in fields such as;

  1. Electrical engineers; a reviewer with a good understanding of electrical appliances and how they work will be essential to a team of reviewers.
  2. Software engineering; one with expertise in this field would be a viable option for a review team.
  3. Manufacturing; this goes without saying as whatever is being designed will eventually need to be manufactured. 
  4. Quality assurance; someone needs to be able to check the quality status of the design.
  5. Regulatory affairs; guidelines must be followed and the necessary rules adhered to and this is where someone with such skill comes in.
  6. Mechanical engineering; this reviewer will be capable of understanding the mechanics of the product.

Others include reviewers in marketing and clinical and also customers (either through direct or indirect participation). Lastly, an important member of the team is the independent reviewer who bears no direct responsibility but has a technical understanding of the device and brings a fresh perspective to the table. 

Systematic Process.

We have said that the design review follows a systematic process that allows for the documentation of the progress of the design. Should there be any need to update the design, the new changes would have to be effected in the design input document. Depending on the level of changes made, there may also be a need to redesign the product or simply change the labeling.


Related Links

OrcaMotive ASPICE Event Madrid Spain 2019

June 18th, 2019 Posted by Requirements Management Tool 0 thoughts on “OrcaMotive ASPICE Event Madrid Spain 2019”



Tel: +972-3-537-2561

OrcaMotive Event – Madrid Spain 2019

¡Usted está invitado a nuestro evento OrcaMotive! Orcanos es un proveedor líder en el ciclo completo de gestión de cumplimiento para la industria automotriz.

Este evento presenta consejos y tecnología para cumplir con los requisitos de cumplimiento y regulaciones de la industria automotriz. El mismo discutirá cómo actualizar su organización respecto a los requisitos de ASPICE e ISO 26262 utilizando tecnología y herramientas avanzadas.

You are invited to our OrcaMotive FREE event! Orcanos is a leading vendor in the compliance lifecycle management for the Automotive industry.

This event showcases tips and technology to meet the compliance and regulation requirements for the automotive industry. The event will discuss how to bring your organization up to speed with ASPICE and ISO 26262 requirements using advanced technology and tools.


 Wednesday, 17th July 2019 at 13:00 PM

 Paseo de la Castellana 43, 28046, Madrid Spain
Mr. Benny Prujan | Director, Program & Functional Safety Manager |  Valens Semiconductor, Israel

Functional Safety Introduction

Mr. Rami Azulay | Head of Sales and Marketing | Orcanos, Israel

Quality system requirement and implementation for ASPICE compliance requirements

Copyright © 2019, @ All Rights Reserved. |

cGMP – Design & Development Plan (DDP) – ISO 13485:2016(6) Clause 7

May 11th, 2019 Posted by Requirements Management Tool 0 thoughts on “cGMP – Design & Development Plan (DDP) – ISO 13485:2016(6) Clause 7”

Defining the stages of design and reviewing every stage of the design process is one of the requirements of ISO 13485 Section 7.3.5 for design and development. The task of identifying and reviewing designs at every stage is accomplished using the design control SOP. Once the User Requirement and Specification (URS) for a medical device is established, the next step in the planning stage is the Design and Development Plan (DDP).

Every product has its unique design and development plan, and they appear in the products documentation as either DDP or D&DP.  There are two main things to consider when creating a Design and Development Plan for a medical device.

  1.      Draft the plan and approve it using the design control system.
  2.      At crucial moments in the design stages, update and review the plan.


What is in the DDP

The Design and Development plan will differ with the complexity of each product as well as with the organization that produces them. For a simple product, the DDP can be in the form of a basic flow chart. However, with a more complex product, the design and Development plan will be in the form of a well-detailed Gantt chart.


The first thing that the DDP should cover is the objectives and goals for the product. This will help clarify the purpose of designing the product and its functions. Next, the DDP should note the various departments involved in the designing of the product and their roles. In addition to that, information on contractors or sub-contractors that will be contributing to the project. The assignment of responsibility as well as documenting them is vital to the success of the product design. Likewise, collaborations and shared responsibility should be elaborately defined to eliminate ambiguity or confusion. This is vital if the project involves multiple teams or departs.

The design and development plan should also have a breakdown of tasks alongside the people/team responsible for them. The task breakdown should include the following;

  • The time duration for the product design.
  • The resources that would make the project a success.
  • Individual responsibility for set tasks.
  • Allocation of resources.
  • Criteria for fulfilling each task
  • Collaboration points and the teams are collaborating on a specific task.

The task breakdown will help optimize the time it takes to complete the product and get it ready for the market. There should be a report documenting the target for each task, and it should have tests and studies that prove that the product is safe for use. Some of the tests and studies to consider are as follows;

  • Shipping studies
  • Biocompatibility testing
  • Validation of sterilization processes
  • Non-Clinical animal studies
  • Electromagnetic Field (EMF) Interference studies
  • Mean-time-to-failure-studies
  • Clinical evaluations


The tests and studies to be conducted will depend on the type of product design and the function of that product.

Another set of criteria that should be present in the design and development plan is what to expect from the activities of design transfer, and how to monitor what is being transferred. The expected result from the design process should also be weighed against the process input.

Problem with Design and Development plan

The biggest problem that comes with a DDP is the way the project manager tends to overestimate the product design timeline. Usually, such a problem arises with a lack of experience, lack of optimization and flexibility to the plan, and trying to work backward. It is important that tasks are completed on time, but there should be room for updates to account for unforeseen circumstances in the design process.

Related Links

cGMP – Customer Related Processes and Requirements – ISO 13485:2016(4) Clauses 7

May 4th, 2019 Posted by Requirements Management Tool 0 thoughts on “cGMP – Customer Related Processes and Requirements – ISO 13485:2016(4) Clauses 7”


The purpose of Customer Related processes as stipulated in the ISO 13485:2016, is to make sure that companies keep to a high standard when it comes to the products and services they offer to customers. In other words, it is a way of ensuring that the customer is the focus of the company and its product.

What the ISO 13485:2016 is hoping to achieve is a document that outlines an established User Requirement. The practice which started with the software industry helped to ensure that products meet the desired outcome of the end-users. Companies in today’s world, are concerned with how the user interacts and experiences the product, rather than what they need in their design process. Hence, abandoning the need for User Requirement for User Experience.

Apple products are an example of how design focuses on user experience instead of user requirement. Henry Ford, the famous founder of Ford Motors, made a quote that reveals a unique flaw with user requirement. He said that if he had been opportune to ask people what they required, they would have responded that they needed faster horses rather than cars.

While the software industry is embracing the concept of user experience, the medical device industry is still relying on user requirement. Although there is hope that the medical device sector will get there, we will be addressing User Requirement Specification (URS) as a part of the ISO 13485 clauses for customer-related processes and requirements.

Considerations Demands by ISO 13485 for Product Requirement

One of the most vital requirements for the product, as stipulated in the ISO 13485 clause, is the requirement for both delivery and post-delivery of products. There have been cases where companies failed to supply requirement for products as they relate to the installation, maintenance, training, packaging, calibration, and servicing. The ISO 13485 does mandate that these requirements be available and if they aren’t, they should be a justified reason for their absence.

Typically, not all products require all parts of the requirements. For example, the User Requirement Specification (URS) for a disposable device might only contain a section that justifies why there is no product requirement for calibration, servicing, maintenance and training. Additionally, another critical information stated in ISO 13485 is the fact that requirements not mentioned but needed for the product use will be identified. The stipulation helps to address the intent for consideration for product requirement during usage.

A disposable contact lens is an ideal example in clarifying implied consideration for the product requirement. Let’s say that the average shelf life for the contacts is 2 years as stipulated in the product requirement. However, the contact usage life cycle after the customer opens the seal is not accounted for in the requirement. Hence, should a customer use the lens for a week consistently before discarding it, while testing under such conditions has no to be done, implied product requirements means that the company has violated a requirement under the ISO 13485. Likewise, companies have to fulfill all applicable requirement such as the region and market for the product to best determine which product requirement to follow and note them in the product requirement document. In totality, even though the requirements may be specified or implied, they have to be met.

Product Requirement Review before commitment

This section of the ISO 13845 mandates the review of the product requirement long before the product gets to the customer. The review should cover the following;

  • The documentation and definition of product requirements.
  • The fulfillment of all applicable regulatory requirement.
  • Updates on contract requirements that exist in previous product requirements.
  • The capability of companies to satisfy the requirement.
  • Planning and execution of required training.

All the review requires are pretty standard and can be met easily. The design and development team is responsible for the generation, design, and review of a URS document. Similar to every other report, the User Require Specification document will be revised for the entire length of a product. It is crucial that recisions be tracked and noted and more critical, changing numbering each revision or updates should be avoided as references to previous updates is a possibility. Similarly, with each new update and stage in the development of a product, the URS should be revised and updated. The same principle applies to contract updates for customer-based products as changes that exist with previous requirements need to be addressed.


Communication is the last major part of customer related process under ISO13485 and must be appropriately managed. All forms of communications with customers to be the individual or commercial customer requires careful consideration. A requirement that covers all forms and ways in which communications with customers are performed must be made available. The requirement covers; inquiries about orders, contracts and their amendments, product information, advisory notes, and feedback processes including complaints.

Also, there needs to be a way to categories which customer related communication that should be submitted to regulatory organizations alongside a scheduled time and system for the process. The communication that organization submits will vary with where they market their product and the industry category of their product.


Related Links

אורקנוס קפה 30.5.2019 – כנס איכות למצויינות

April 1st, 2019 Posted by Requirements Management Tool 0 thoughts on “אורקנוס קפה 30.5.2019 – כנס איכות למצויינות”
להרשמה לחץ כאן

מובילים את האיכות למצויינות דרך אנשים, כלים ומתדולוגיות

רח תוצרת הארץ 8, תל אביב. קומה 11 (בניין  Toha)

אורקנוס קפה חוזרת!

מפגש נוסף של מיטב אנשי האיכות בתחום של פיתוח ציוד רפואי, המאפשר דיון בסוגיות החדשות בתחום האיכות. במפגש נדון באתגרים של שנת 2019 ו 2020 וינתנו טיפים לעמידה בהתאמות החדשות לתקינה של 13485:2016 ISO במעבר מ- MDD ל- MDR

להוספה ליומן גוגל

הכנס הינו ללא עלות, אך דרוש רישום מוקדם

Links to presentations:

תוכנית הכנס

  • 18:00 – 18:30 – התכנסות וכיבוד קל
  • 18:30 – 19:15 – הרצאה בנושא העדכונים והיישומים של השינויים ב ISO 13485:2016 וה MDR מול MDSAP (אירית באומן, מנהלת אבטחת איכות באי.בי דנטל ישראל) – The Best Tips for the QA – RA 2019-2020
  • 19:30 – 20:15 – הרצאה בנושא ניהול קבלני משנה ואישור ספקים ומפיצים לפי דרישות ה- MDR החדשות (קרן צבר, יועצת איכות וולידאציה בלודן) – Purchasing Controls- ORCANOS Cafe 30.05.2019
  • 20:15 – 20:30 – דברי סיכום – The War On Paper – A Plan for going paperless

להרשמה לחץ כאן

Orcanos Innovation Platforms to Meet Automotive Compliance Standards

March 14th, 2019 Posted by Requirements Management Tool 0 thoughts on “Orcanos Innovation Platforms to Meet Automotive Compliance Standards”

System Engineering Process Group (SYS)


Compliance standard in the automotive industry: Vehicle manufacturers understand the importance attached to comply with standards in the automotive industry. Having to comply takes into account, the safety of such a vehicle. As a result, compliance agencies have come up with several compliance codes that decide the level of compliance of the automotive in terms of safety. Some of them include the following:

  1. IEC 61508 (Functional Safety of Electronic/Electrical/Programmable Electronic Safety-related Systems).
  2. ISO 26262 (Road vehicles – functional safety)
  3. Automotive SPICE (Software Process Improvement and Capability Determination). Also referred to as ISO/IEC 15504
  4. Capability Maturity Model Integration (CMMI)

For this writeup, our focus is on 2 and three, i.e. ISO 26262 and Automotive SPICE.

The ISO 26262 is an improvement on the IEC 61508. Its goal is to determine the level of safety/risks in the functional use of an automotive. By doing this, it accesses the electronic functionality of the vehicle from conceptualization, design, creation, and production. Its goal is to ensure that vehicle safety is paramount especially for its habitats. Since the 2009 publication of the (DIS) of ISO 26262, this ISO has gained traction. With legal practitioners using it as a standard in defending cases. It uses a set of guides that help to determine the compliance level of a system: either software or hardware. It provides the safety lifecycle, the risk classes; it gives the safety requirements through the AILs for minimizing residual risk to an acceptable minimum and provides a validation method for ensuring that vehicle manufacturers meet a safety standard.

Automotive SPICE is also known as ASPICE. It is a set of really technical documents that assist in the creation and adherence to electronic software safety and functionality. ASPICE provides the working standard that is needed for manufacturers to achieve regulatory fixed standards of electronic software for their vehicles. Automotive SPICE is a document duly owned by the VDA (Verband Der Automobile industry e.V. ASPICE has a Process Reference Model document that’s crafted for this particular industry.

The PRM consists of the PRM consists of the Primary Life Cycle, Organization Lifecycle, and Support Lifecycle. The Primary Lifecycle then consists of the Acquisition, Supply, System Engineering and Software Engineering Process Groups. The Acquisition group, also termed the customer acts ACQ. And it includes the following: Agreement, monitoring, technical demands, Process, and Legal requirements. The supply group consists of the process release and supply tender. The system group includes specification, design, integration and qualification test. The Software engineering group provides analysis, design, construction and verification, integration and communication.

The ASPICE document module is a set of technical documentation that is needed for the implementation of a full standard electronic software for an automobile. The ISO 26262 on the other hand, is a document that consists of technical implementation standards that are needed for the standardization of the functional safety of the vehicle.

Orcanos Unveils New Corporate Headquarters

February 3rd, 2019 Posted by Requirements Management Tool 0 thoughts on “Orcanos Unveils New Corporate Headquarters”

New Facility Sets Stage for Software Solution Provider’s Future Growth

TEL AVIV CITY —Feb 3, 2019 — Orcanos, a global provider of enterprise software solutions for life science and other regulated companies, today announced it has moved into its new corporate headquarters. The completely renovated space at 24 floors designed by the distinguished architect Ron Arad who was granted the liberty to create an unblended building which is located in the central junction of the city of Tel Aviv, Israel.

Our employees will work in the new building, the new HQ was carefully chosen with longevity in mind. Orcanos foresees future growth that will expand its workforce in Tel Aviv and we selected a location that is accessible to all of Israel citizen with an easy trip by train.

“We are proud to be a Tel Aviv-based company for over 14 years, and when choosing a new office space to accommodate our growth, we wanted a location that offers the best of Tel Aviv, Israel” said Zohar Peretz, CEO of Orcanos. “The urban view from the building to all major sites and its premier location close to downtown Tel Aviv, as well as being just minutes away from some of the finest attractions and outdoor recreation activities in the nation, all to provide an environment that is conducive to innovation. It has nearby amenities to also enable a happy work-life balance, community interaction which is an important part of our company culture.”

In addition to choosing an ideal location for employees, the building features a high-tech modern design, with open floor plans for collaboration. Space features expansive breakrooms that are fully stocked with complimentary food and meeting rooms that are designed to encourage teamwork.

“We provide our employees with the best possible facility for the collaborative and innovative culture that has fueled Orcanos for the past 14 years,” said Rami Azulay Orcanos VP Marketing & Sales.

Media Contact:

Kfir Peretz

Internet Marketing


Orcanos 4.0 new release now includes a complete training program plan to support the GMP process

January 8th, 2019 Posted by e-GMP, Requirements Management Tool 0 thoughts on “Orcanos 4.0 new release now includes a complete training program plan to support the GMP process”

Orcanos 4.0 new release now includes a complete training program plan to support the GMP process. The Orcanos new release involves a set of optional training tasks with a list of topics and agenda to be covered in order to be in compliance with the GMP. These training topics are covering Medical Device and Pharma producers including Cannabis growers who need to comply with the enforcement of the strict regulations by the legislation of the local government.

Orcanos as a world leader in the eGRC and eQMS and ALM market happy to get you the list of topics in a specific each subject area according to your professional demands, please simply click to get your FREE edition.

Some covered subjects below:

  1. Quality Assurance
  2. Microbiology
  3. GMP in Pharmaceutical Development
  4. GDP
  5. Computer Validation
  6. GMP for APIs and Excipients
  7. Medical Devices
  8. Packaging
  9. GMP in Biotechnology
  10. Regulatory Affairs
  11. Quality Control
  12. Sterile / Aseptic Manufacturing
  13. Technical Operations
  14. Validation
  15. GMP Basic Training Courses
  16. Data Integrity

Here are some of the benefits of using Orcanos  as the foundation of your e-GMP system:

  • Automation and Standardization: With Orcanos eGMP software, you can standardize all documents-based processes and automate distribution/routing, review, follow-up, escalation, and approval of documents. It makes search and retrieval of documents faster and easier.
  • Centralized Platform: Orcanos can serve as a centralized platform for all quality documents and records critical to eGMP compliance, making it essentially your eGMP system. Orcanos is web-based so authorized users have access to the system from virtually anywhere 24/7 not holding your production line and allow granting confirmation service without the local presence or human resources.
  • Connectivity: Orcanos is unlike other eGMP software solutions in the sense that it can connect all quality processes, including document control, training control, audit management, nonconformance management, CAPA, MRB, DHR and change control. This connectivity will help ensure that quality and other issues will not fall through the cracks.
  • Mobile Access: With Orcanos adoptive technology, users can access the system using a tablet or a smartphone. This capability is a distinct advantage of Orcanos over other eGMP software solutions and it can be very helpful for users out in the field or those constantly traveling. Those users will be able to participate in documents-based processes critical to eGMP compliance even when they are not in their local office.
  • Validated System – Orcanos is a validated system that no customization requires any effort invalidation. It is fully CFR 21 Part compliance system and already servers many customers around the world.


Page 1 of 5
1 2 3 5


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

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