QPack Medical Webinar, October 2012

November 11th, 2012 Posted by IEC 62304, ISO 13485, ISO 14971, Requirements Management, Risk Management, Software Lifecycle Management, Test Management, Validation and Verification 0 thoughts on “QPack Medical Webinar, October 2012”

QPack ALM and Teamcenter PLM Integration

November 11th, 2012 Posted by Requirements Management Tool 0 thoughts on “QPack ALM and Teamcenter PLM Integration”

QPack Risk Form According to ISO14971

October 23rd, 2012 Posted by IEC60601, ISO 14971, Risk Management 0 thoughts on “QPack Risk Form According to ISO14971”

Following is breakdown of each phase in the risk management process described in ISO 14971:

4. Risk Analysis
4.3. Hazard Identification

  1. Describe the hazard
  2. Select risk category
  3. Define the feature/function hazard relates to
  4. Describe Potential harm
  5. Describe Cause of failure

4.4. Risk Estimation

  1. Define probability of harm due to hazard
  2. Define severity of harm due to hazard
  3. The risk level (RPN=Risk Priority Number) is automatically calculated

5. Risk Evaluation

Decide whether risk should be controlled by the predefined acceptability zone (Acceptable, ALARP, Unacceptable)

6. Risk Control

6.2 Risk Control Measures

Define control type

6.4 Final Risk Evaluation – Residual Risk

  1. Define probability of harm due to hazard
  2. Define severity of harm due to hazard
  3. The residual risk level (RPN=Risk Priority Number) is automatically calculated

6.6. New Hazard

A new   hazard created? (yes/no)

7. Verification and validation

Evaluation of overall residual risk acceptability

Use QPack traceability to relate artifacts used for risk control.

The test cases (verification) should be connected to design artifacts to assure verification

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.

Page 16 of 20
1 14 15 16 17 18 20


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

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