Risk management terminology and characteristics

August 30th, 2012 Posted by IEC 62304, IEC60601, ISO 14971, Risk Management, Standards and Regulations 0 thoughts on “Risk management terminology and characteristics”
Basic terms
  • Hazard: Potential  source  of  harm (what can go wrong)
  • Failure cause: what causes the hazard
  • Harm: Physical injury or damage to  the of people or property
  • Risk: the calculation (RPN) of the Probability of occurrence of Harm and its Severity
  • Risk control/ Risk mitigation: the means taken to reduce the risk
  • Residual risk: Remaining risk after risk control measures have been implemented

So, Hazard creates the risk that can cause harm: what can go wrong, what is the likelihood for this to happen, what would be the consequences and is the risk level tolerable or not?

Example 1 : Risk analysis to mobile phone: The radiation (hazard) that caused because of crack in mobile phone body (failure cause) causes severe headaches (harm) solved by using materials according to relevant standards (risk control)

Type of optional hazards – hazard category (partial list)

  • Energy
  • Biological
  • Chemical
  • Environmental
  • Hazards Related to the Use of the Device
  • Functional Failure
  • Maintenance
  • Aging
  • more…

Risk probability/frequency values (the probability for the harm to occur)

  • Improbable (So unlikely, it can be assumed occurrence may not be experienced)
  • Remote (Unlikely, but possible to occur in life of an item)
  • Occasional (Likely to occur sometime in life of an item)
  • Probable (Will occur several times in life of an item)
  • Frequent (Likely to occur frequently)

Risk severity values (the severity of the harm!!)

  • Negligible
  • Minor
  • Moderate
  • Major
  • Catastrophic

Risk control types

  • Safety by design
  • Protective measures – in the medical devices itself or in the manufacturing process – alarms, production line tests
  • Information for safety – marking, user manual
  • Operational – Workshops, training courses…

Risk properties

  • Hazard – what can go wrong
  • Category – see list above
  • Failure cause – what cause the hazard
  • Condition – Normal use, single fault, incorrect use
  • Affected – Patient, operator, service personal, bystanders, environment
  • Probability1 (also known as occurance/likelyhood/Frequency) – probability of the harm before risk control
  • Severity1 – severity of the harm before mitigation
  • RPN1 (risk level1) – the risk estimation result (Severity and probability) before mitigation
  • Control type – see above
  • Reduction necessary? – yes/no for hazards that are in ALARP zone
  • Probability 2 – after mitigation (risk control)
  • Severity 2 (not always in use, usually equal to Severity1)
  • RPN 2 – after mitigation
  • New hazard created – yes/no. Indicates if new risks arises from risk control
  • Related artifacts (for control) – relations to SRS, HRS, user manual…
  • Status – risk status, see in our blog some examples (hazard identification->risk estimation risk control identification->risk control implementation->verified)
  • Verification type – external labs, test management, training (you can use a descriptive field as well)
  • Verification description
  • Applicable component

risk management procedure

July 30th, 2012 Posted by IEC 62304, IEC60601, ISO 14971, Risk Management, Software Lifecycle Management 0 thoughts on “risk management procedure”

Please review posts Risk management terminology, risk management file before reading this post

Risk management is supported by the following activities:

Risk management

  • Risk Assessment
    • Risk analysis (part of risk assessment)
      • Hazard/hazardous situations identification
    • Risk evaluation (part of risk assessment)
      • risk estimation
      • including acceptability evaluation
  • Risk control
    • Define effective control of the risk
    • Control implementation
  • Post production
    • Monitor risk control effectiveness

A device may contain some risks eventually, but it must be free from UNACCEPTABLE risks

IEC 60601-1 Third Ed clause 4.2 requires RM process (RMF)

Potential risk forms in QPack (partial fields) – click to enlarge:

Risk management File

July 30th, 2012 Posted by ISO 14971, Risk Management 0 thoughts on “Risk management File”

Set of documents which contain information of the activities performed during the Risk Management process

The RMF should include:

  • General management policies, procedures and practices to the tasks of analyzing, evaluating, controlling and monitoring risk
  • Links do other company document (such as quality system)
  • Risk analysis, risk evaluation, implementation and verification of the risk control measures, the assessment of acceptability of any residual risk
  • Reference to RM team
  • Risk management plan
  • Intended use including answers to questions that can be used to identify medical device characteristics that could impact on safety
  • Identification of hazards and hazardous situations
  • List of critical components and the relevant information for all identified hazards
  • Data used and the sources (e.g. accident history, risk reduction applied to similar medical devices)
  • Relevant assumption that have been made (e.g. users, environment, safety factors, means of protection, etc.)
  • Tools for failure analysis and result of failure analysis
  • Estimation of the risk of each hazard and hazardous situation
  • Risk evaluation
  • risk control
  • Risk reduction (residual risk evaluation for control measures not derived from a standard)

ATI – Advanced Medical Technologies selected Orcanos QPack Medical ALM solution

July 23rd, 2012 Posted by Customers, Events 0 thoughts on “ATI – Advanced Medical Technologies selected Orcanos QPack Medical ALM solution”

Orcanos Welcome ATI,

ATI Advanced Medical Technologies is a developer of non-invasive diagnostic devices for the ophthalmology market. The Company has two products in its portfolio, a non-invasive pupil dilation device, called the FIM and a non-invasive tonometer to measure intraocular pressure, called the NIT. 

ATI has selected Orcanos solution to support their product development lifecycle SDLC which is stands for regulation and standard that needs to meet with 510K and other requirements. QPack system will support ATI change management process and software validation as well and will be producing all relevant document for ATI customers. At the same time ATI exposure to top industry suppliers now to examine QPack support the validation procedure required by IEC 62304, IEC 62366, ISO 14971 and 61601 3rd edition for Computerized System, Information Technology and others. Having ATI under Orcanos list of customers serves Orcanos agenda in the past 5 year to be a leader solution provider for the Medical Device and aligned industries. We have been continuously working on QPack Medical™ to meet every change in authorization body requirements and standards. We are now moving forward with the Mobile Health changes and completing our product to allow small application vendors to be able to reduce the cost of compliancy by streamlining all the data under single repository – QPack Medical™.

5th Annual Medical Devices Software Development Summit – presentations

July 6th, 2012 Posted by Software Lifecycle Management 0 thoughts on “5th Annual Medical Devices Software Development Summit – presentations”

List of presentations:

Dr. Ingo Wundrich talks about implementing QPack for a small medical device startup

Oren Tamari talks about implementing a full ALM solution in Argo Medical

Zohar Peretz presents QPack Medical solution next generation

Dina Sifri talks about software development for medical device

Development under regulations

May 10th, 2012 Posted by Requirements Management Tool 0 thoughts on “Development under regulations”

Strange as it may sound, development processes under regulatory supervision can actually be profitable for all concerned

By: Rami Azulai, joint CEO of Orcanos

In today’s decentralized and global development environments, we are also in need of a solution to provide tools for management, control and supervision throughout the entire product development project – from the stage of the requirements, planning and testing, to implementation of the software for the customer. It is not surprising, therefore, that in recent years the field of ALM (Application Life Management) has been enjoying accelerated growth among suppliers of software for implementing effective ALM solutions that create transparency and integration among the different development entities in the organization.

Many software companies around the world have already identified the advantages of implementing ALM systems, allowing different people in the organization to follow up, monitor and supervise the entire development process. In this way, at each point in time different officeholders can obtain an accurate picture of the product, not only in the development and testing sections, but also the marketing managers, who are in regular contact with the customers and update them regarding progress of the development and meeting their demands. In this way, there is full transparency throughout the entire development process, with everyone “talking” to each other with a single platform and a single source of information. This also avoids the problem of lack of communication, as the marketing manager can ensure that the developers have understood the customer’s requirements and are working according to them, and avoids development problems or situations in which the poor flow of information is liable to create delays and unnecessary work for the developers. This is particularly true in today’s age of globalization, when development companies employ software and control staff scattered at different sites around the world.

Alongside the increased awareness of the advantages provided by the ALM tool, we can expect a parallel trend of regulatory and supervisory bodies guiding the development processes and, in practice, creating standardization of the field. Today it may sound very far off, but it works in certain fields, such as biomedicine, for example, or the development of military and security systems. Today, biomedical companies are required to comply with FDA standards, and even certain telecom companies have to meet the TL 9000 standard, and the ALM systems are necessary to prove that they are in fact in compliance with the development processes and all the quality standards. It must be remembered that these companies cannot realize their business targets without the regulatory processes, and so such systems are seen as essential to their existence.

The implementation of regulatory standards will make it possible to ensure that the customer, who purchases a software product and is also required to meet high quality standards, can be certain that the development that has been ordered does in fact comply with all the most stringent regulations and standards. Furthermore, among those who are currently expressing an interest in measures of this kind are investors and venture capital companies. The reason for this is simple. When a venture capital fund or a private investor invests in a company or product, it wants to be certain that the company does indeed meet quality and effective work standards, and is not “burning” precious cash and personnel resources as a result of poor quality software products. With the ALM tool, it is possible to guarantee that the company in which they are investing is indeed capable of meeting the targets set in its business plan, and following up its performance in an ongoing and direct manner.

The development companies should also welcome such a step. Standards can only make their work easier. This does not mean that people will work harder, on the contrary – communication through the ALM tool can significantly increase efficiency, and thus streamline and improve the process at every level. There is regular, online communication, and times for responding and giving answers to the customer are considerably better, and in line with the customer’s expectations. In this way too we avoid the complexity that characterizes many software companies, which reach a situation in which the customer is dissatisfied and returns again and again to the developers, asking for a new version without bugs and problems.

In conclusion, the introduction of standards and regulatory intervention often sounds like something that will delay to market processes and cause difficulties. In the case at hand, there is no doubt that development processes supervised by means of an ALM tool can create a win-win situation and streamline development processes, no matter how complex and sensitive they are.

Requirements management in medical device

May 10th, 2012 Posted by Requirements Management 0 thoughts on “Requirements management in medical device”

Medical device industry

The medical device industry is a rapid-growing industry, and so is the complexity of device technology. Medical device corporate chemical and biological ingredients and can also combine a complex mechanisms and electronic systems. Operating such systems requires complex software.

The challenge in developing medical device

Many questions are raised planning and developing such software: What should it do? How can we validate its operation? How can we predict the required effort estimation and how can we track its progress as time pass? The medical device must operate in high-level accuracy of thousandths of an inch, and measured in nanoseconds.

Market requirements

The goal of this module is to gather all the requirements of the device. The process of gathering requirements for a new device, or application is one of the most important phases in the development process. In order to meet company goals, these requirements must reflect customers and end users needs as well as company requirements. Market requirements come from multiple sources, such as company documentations, competitors, domain experts, marketing department and prospective users.

Gathering data from multiple resources demands a systematic process. QPack Medical MRD provides a structured system for collecting data from them, synthesizing, and then rationalizing and reducing the data. This last step is needed to remove conflicting or redundant requirements, and eliminate or annotate those requirements that are impractical based on current technology, cost constraints, or market factors.

Last stage in this process is to trace these requirements and verify they are delivered.

QPack requirements management

QPack requirements management creates a central information repository, which includes all requirements data, such as description, attributes, status information, and other information. Requirements and their associated attributes can evolve, be adapted, and be reused for subsequent development projects, lowering the overall development cost. This repository not only defines the specifics of what the system should do, it assists managers in set priorities and effort estimation, and provides up-to-date information of project progress.

QPack systematic approach allows organizing, documenting, and managing both the initial and the changing requirements of a system. A primary result of this effort is the development of one or more requirements specifications that define and document the complete behavior of the system. It allows better definition and management of the labeling claims, allows better control of the project, improve quality by combining the validation phase into the process and allows each participant in the process to understand what he should deliver. By improving team communication, and provide professional tools, Project cost is reduce significantly.

Integrate Market Into Development

May 10th, 2012 Posted by Requirements Management Tool 0 thoughts on “Integrate Market Into Development”

Trends in ALM domain

Key trends in the development lifecycle include Product Data Management (PDM), and more and more ALM (Application Lifecycle Management) solutions find their way to organizations dealing with software development. The most important challenge is to efficiently integrate product development with product management, by creating a communication channel between the development team with the product management.

Challenge of product management

Successful product management includes the combination of marketing, R&D, high quality assurance and deployment in one integrative process. Turning market information into products is the key to successful business. However, inputs from markets are often misunderstood, or lost along the way. Moreover, inputs can be extremely complex and demanding. These inputs need to be assessed from various points of view, such as complexity, market valufe and costs.

Benefits of integrating product management to development team

Product Management delivers benefits to both the provider and the consumer, by integrating the customer needs into the development. The provider is benefited because he is producing better products that find consumer needs, thus becoming competitive. On the other hand, the consumer benefits because he gets better quality product that finds his needs.

How QPack integrates market to development

Gather: QPack provides a professional tool for the product manger, allows him to gather and trace market requirements derived from customers and end users.

Define: These requirements are managed as first phase of the development process, and the development team defines the product features, based on these requirements. This gives strong traceability between market requirements and product requirements (features).

Trace: The product manager can easily trace each market requirement and review the product features designed to solve it. He can also see for which version each market requirement is planned for.

Drill: The product manager can also trace deeper if necessary, and review each requirement activities, in terms of coverage and quality.

qpack medical 21 cfr part 11

May 1st, 2012 Posted by Requirements Management Tool 0 thoughts on “qpack medical 21 cfr part 11”

Using software system  in the medical device development process requires compliance of software systems with the  IEC 62304.

QPack support for IEC 62304:

– Assure software system electronic records integrity control

– Manage your software system requirements specifications

– Manage and control the validation and verification process (V&V)

– Dynamic testing

– White Box and black box testing

– Test results summary

– Generate validation reports  with a click of a button

– Risk and hazard management

Assure software system electronic records integrity control

In fact, you can use QPack integrated ALM modules to assure your software system electronic records integrity. The following chapters discuss this capability in details

Manage software system requirements specifications in QPack

The company required to make SRS for every software system used by the company, Regardless of whether the computer system is developed in-house, developed by a contractor, or urchased off-the-shelf, establishing documented end user (i.e., a person regulated by FDA) requirements is extremely important for computer systems validation.

QPack ALM provides a complete Requirements management tool, including the ability to generate the required documents with a click of a button, embedding the traceability matrix table automatically. QPack provides software requirements’ traceability at all times to risk and hazard assessment process, and validation plan according to part 11 key principle, to optimize the application Lifecycle Management process.

The following image shows the establishment of end user’s needs and intended use using QPack hierarchical product requirements tree

Later on you are able to obtain evidence that the computer system implements those needs correctly and that they are traceable to system design requirements and specifications using QPack  CFR part 11 document generation module and its dynamic filter capabilities.

The image above demonstrate the generation of the SRS to MS-Word document using QPack CFR part 11 document generation module




QPack provides the ability to embed query results inside documents, such as traceability matrix (shown in the image above), unresolved anomalies (defects and bugs), verification results (actual testing results), etc.

Manage and control the validation and verification process with full traceability

The FDA considers thorough documentation to be extremely important to the success of your validation efforts. Validation documentation should include a validation plan, validation procedures, and a validation report, and should identify who in management is responsible for approval of the plan, the procedures and the report.

QPack allows you to manage all required validation process.

Validation Plan

The validation plan is a strategic document that should state what is to be done, the scope of approach, the schedule of validation activities, and tasks to be performed. The plan should also state who is responsible for performing each validation activity. The plan should be reviewed and approved by designated management.

– QPack test management tool allows you to plan your testing procedures in order to validate the defined requirements, with full traceability between the tests and the requirements.

– Each validation task is assign to the relevant stakeholder using the workflow mechanism.

– QPack CFR part 11 document generation module allows you to generate the evidence document for your test plan and its traceability matrix, including tests results.


The above image demonstrate a relation between 2 requirements in QPack

Validation Procedures

The validation procedures should include detailed steps for how to conduct the validation. It should describe the computer system configuration, as well as test methods and objective acceptance criteria, including expected outcomes. The procedures should be reviewed and approved by designated management.

QPack test management tool allows you to design each validation procedure as step by step with full description editor.

The use of validation parameters increases the coverage of complex testing environments and provides data reuse of testing procedures.
Validation Report
The validation report should document detailed results of the validation effort, including test results. Whenever possible, test results should be expressed in quantified terms rather than stated as “pass/fail.” The report should be reviewed and approved by designated management. QPack reporting tools allow collecting all test results and summaries them in any evidence document format or structure. QPack is capable to quantify all measurements both into your final report and also during different project stages where KPI’s are required.

Dynamic Testing – test conditions

Test conditions should include not only “normal” or “expected” values, but also stress conditions. Test conditions should extend to boundary values, unexpected data entries, error conditions, reasonableness challenges

QPack includes test parameters in test procedures to manage values with ranges and conditions.

White box and black box testing

Structural testing – Unit test

Structural testing procedure  takes into account the internal mechanism (structure) of a system or component. It is sometimes referred to as “white box” testing. Structural testing should show that the software creator followed contemporary quality standards.

QPack allows you to plan and execute your “White Box” (Unit Tests) and reports results in evidence documents as required by the FDA.

Functional testing – black box testing

Functional testing involves running the program under known conditions with defined inputs, and document test results to pre-defined expectations. Functional testing is sometimes called “black box” testing.

QPack allows you to plan, design and execute your “Black Box” tests and generate your evidence reports which includes both your test step procedures (Expected Results) and your Actual results.

Test results summary

Quantifiable test results should be recorded in both quantified and qualified (e.g. pass/fail) terms. Quantified results allow for subsequent review and independent evaluation of the test results. QPack provides you to produce both Quantified results and with quick access the ability to drill down into deeper understanding of those results. All results can be embedded into evidence documents according to standard.

Extent of Validation – Risk & Hazard

When you determine the appropriate extent of system validation, the factors you should consider includes (but are not limited to) the following

The risk that the system poses to product safety, efficacy, and quality; note that product means the FDA regulated article (food, human or veterinary drug, biological product, medical device, or radiological product);

The risk that the system poses to data integrity, authenticity, and confidentiality; and,

The system’s complexity; a more complex system might warrant a more comprehensive validation effort.

QPack Risk and Hazard embedded capabilities in the system allows you to consider all the above factors and point on the mitigation entities located at any on the above evidence documents. QPack performs all tractability matrix needed to be printed out and also format the information for you according to the FMEA standard.

Medical device validation

May 1st, 2012 Posted by Requirements Management Tool 0 thoughts on “Medical device validation”

Medical device software validation

Medical device validation is a complex process that must be submitted to the strict regulations of the FDA. As a result, routine end-product software validation alone is often not sufficient to assure the medical device software validation. Some end-product testing have limited sensitivity, sometimes destructive testing is required to show that the process is adequate and in certain situations end-product testing does not reveal variations that may occur in the product which may impact safety and effectiveness.

The FDA believes through careful design and software validation of both the process and process controls, a medical device manufacturer can establish a higher degree of confidence. Successfully validating a process will reduce the dependence upon intensive in-process and finished product testing. To learn more about the FDA medical device software validation, you can review General Principles of Software Validation; Final Guidance for Industry and FDA Staff:

Software validation is a critical tool used to assure the quality of device software and software automated operations. Software validation can increase the usability and reliability of the device, resulting in decreased failure rates, fewer recalls and corrective actions, less risk to patients and users, and reduced liability to device manufacturers. Software validation can also reduce long term costs by making it easier and less costly to reliably modify software and revalidate software changes. Software maintenance can represent a very large percentage of the total cost of software over its entire life cycle. An established comprehensive software validation process helps to reduce the long-term cost of software by reducing the cost of validation for each subsequent release of the software.”

QPack software validation module for medical device validation is designed to meet FDA’s Quality System validation requirements such as those in regulatory affairs, quality assurance, process development or manufacturing.

QPack software validation module provides tools for medical device software validation that comply with FDA regulations.

As described in the General Principles of Software Validation; Final Guidance for Industry and FDA Staff, QPack supply the tools to comply with the guideline, described in the following section (chapter 4):


A documented software requirements specification provides a baseline for both validation and verification. The software validation process cannot be completed without an established software requirements specification (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).


Software quality assurance needs to focus on preventing the introduction of defects into the software development process and not on trying to “test quality into” the software code after it is written. Software testing is very limited in its ability to surface all latent defects in software code. For example, the complexity of most software prevents it from being exhaustively tested. Software testing is a necessary activity. However, in most cases software testing by itself is not sufficient to establish confidence that the software is fit for its intended use. In order to establish that confidence, software developers should use a mixture of methods and techniques to prevent software errors and to detect software errors that do occur. The “best mix” of methods depends on many factors including the development environment, application, size of project, language, and risk.


To build a case that the software is validated requires time and effort. Preparation for software validation should begin early, i.e., during design and development planning and design input. The final conclusion that the software is validated should be based on evidence collected from planned efforts conducted throughout the software lifecycle.


Software validation takes place within the environment of an established software life cycle. The software life cycle contains software engineering tasks and documentation necessary to support the software validation effort. In addition, the software life cycle contains specific verification and validation tasks that are appropriate for the intended use of the software. This guidance does not recommend any particular life cycle models – only that they should be selected and used for a software development project.

4.5. PLANS

The software validation process is defined and controlled through the use of a plan. The software validation plan defines “what” is to be accomplished through the software validation effort. Software validation plans are a significant quality system tool. Software validation plans specify areas such as scope, approach, resources, schedules and the types and extent of activities, tasks, and work items.


The software validation process is executed through the use of procedures. These procedures establish “how” to conduct the software validation effort. The procedures should identify the specific actions or sequence of actions that must be taken to complete individual validation activities, tasks, and work items.


Due to the complexity of software, a seemingly small local change may have a significant global system impact. When any change (even a small change) is made to the software, the validation status of the software needs to be re-established. Whenever software is changed, a validation analysis should be conducted not just for validation of the individual change, but also to determine the extent and impact of that change on the entire software system. Based on this analysis, the software developer should then conduct an appropriate level of software regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. Design controls and appropriate regression testing provide the confidence that the software is validated after a software change.


Validation coverage should be based on the software’s complexity and safety risk – not on firm size or resource constraints. The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use. For lower risk devices, only baseline validation activities may be conducted. As the risk increases additional validation activities should be added to cover the additional risk. Validation documentation should be sufficient to demonstrate that all software validation plans and procedures have been completed successfully.


Validation activities should be conducted using the basic quality assurance precept of “independence of review.” Self-validation is extremely difficult. When possible, an independent evaluation is always better, especially for higher risk applications. Some firms contract out for a third-party independent verification and validation, but this solution may not always be feasible. Another approach is to assign internal staff members that are not involved in a particular design or its implementation, but who have sufficient knowledge to evaluate the project and conduct the verification and validation activities. Smaller firms may need to be creative in how tasks are organized and assigned in order to maintain internal independence of review.


Specific implementation of these software validation principles may be quite different from one application to another. The device manufacturer has flexibility in choosing how to apply these validation principles, but retains ultimate responsibility for demonstrating that the software has been validated.

Software is designed, developed, validated, and regulated in a wide spectrum of environments, and for a wide variety of devices with varying levels of risk. FDA regulated medical device applications include software that:

  • Is a component, part, or accessory of a medical device;
  • Is itself a medical device; or
  • Is used in manufacturing, design and development, or other parts of the quality system.

In each environment, software components from many sources may be used to create the application (e.g., in-house developed software, off-the-shelf software, contract software, shareware). In addition, software components come in many different forms (e.g., application software, operating systems, compilers, debuggers, configuration management tools, and many more). The validation of software in these environments can be a complex undertaking; therefore, it is appropriate that all of these software validation principles be considered when designing the software validation process. The resultant software validation process should be commensurate with the safety risk associated with the system, device, or process.

Software validation activities and tasks may be dispersed, occurring at different locations and being conducted by different organizations. However, regardless of the distribution of tasks, contractual relations, source of components, or the development environment, the device manufacturer or specification developer retains ultimate responsibility for ensuring that the software is validated.

So, how does QPack supports these guidelines?

QPack supports any development lifecycle method, and supports all kinds of ALM activities such as requirements, development tasks, unit tests, QA activities and tasks, such as test cases, test scripts, defects and test execution sets. The system admin can define the relevant process and work procedure in the system to comply with organization working methodologies.

QPack manages the full application lifecycle process (ALM), thus allows QA team to start activities early in the process, right when requirements are defined. The work procedures are also defined early in the development phase, and control all development phases.

QPack requirements definition module provides a professional tool designed to gather requirements and trace them later on.

QPack provides a testing module that allows the QA team to implement testing methods and procedures in a controlled and structured way. The use of testing tool, that relates every test with the relevant requirement, assures product quality.

The reporting and analytic tools allow users to trace coverage of requirements by tests, thus assure the medical device validation process, and measure product quality.

Page 15 of 19
1 13 14 15 16 17 19


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

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