Posts in IEC 62304

Orcanos QMS: Regulation Compliance & Governance Engine

August 7th, 2017 Posted by Document control, IEC 62304, IEC60601, ISO 13485, ISO 14971, regulation compliance 0 thoughts on “Orcanos QMS: Regulation Compliance & Governance Engine”

Orcanos is about to launch its QMS-Regulation-Compliance engine as part of Orcanos integrated ALM and Quality Management Software System.

Abstract

Compliance best practices lie at the heart of all standards-based regulations and good quality management, such as ISO 14971, IEC 62304 and ISO 13485. However, it is a challenge to keep compliance without electronic QMS, or using traditional ALM tools, as most of them are R&D driven, and lack the support of the quality management software system. Compliance remains a leading concern for regulated industries such as Medical Device, Pharma and automotive.

Orcanos QMS Compliance engine

The powerful new capabilities of Orcanos Compliance Engine would simplify the way companies govern and control quality and regulations, and will provide a “Virtual Auditor” that would scan the project data in respect for specific industry regulation, and quality best practice, such as compliance with ISO 14971, IEC 62304 and ISO 13485 and more.

Orcanos QMS Compliance Engine is a flexible tool that allows companies define any regulation in a simple Excel or Google Sheet, defining the standard, section, classification in case of medical device (CLASS I, II, III), Remediation, and many other parameters, ans then import these regulations into Orcanos ALM and QMS platform and connect it to their projects records.

Orcanos QMS Compliance Engine then scans project data based on the specific regulations, and specific logic attached to it, and shows the faults in a graphical presentation. Together with Orcanos dashboard and notification mechanism we provide quite a good control and monitoring platform

Defining a compliance audit item

Define any compliance audit, setup and customize each compliance item

Compliance Audit

Running a compliance audit check

This is an example of an “Virtual Auditor” that inspects the compliance of specific product with the ISO 14971.

Running Compliance Audit Check

 

Effective baseline management for ORCANOS | ALM Test Management

June 23rd, 2016 Posted by IEC 62304, Test Management, Tip Of The Week, Validation and Verification 0 thoughts on “Effective baseline management for ORCANOS | ALM Test Management”

ORCANOS | ALM  versions and baseline management have similar behavior as a source control, thus provides powerful and intuitive tools to manage and track versions, provides a full change history, prevent duplication, and allows reuse, using pointers (copy as link). orcanos

Overview

Rather than manage versions manually, ORCANOS | ALM has a built-in versions management engine, thus allows storing multiple versions views for single text case, or group of test cases, and handle each version separately, and this without duplicating information.

Test Execution

For instance, the historical steps results can be viewed at the point the execution of the test was performed. ORCANOS | ALM “Execution Set” is used for grouping test for execution. Once executed, the execution set stores historical data throughout each test cycle, and the full change history can be viewed in the “Execution History” tab.

Version views and baseline

As opposed to the common use of other test management tools, that physically duplicating test cases when project version advances, ORCANOS | ALM system maintains pointers of the previous version (which would act as a baseline), and track the changes in the current baseline. Test Cases information from older versions are kept, and once a test needs to be updated, Orcanos provides a BRANCH option that splits the test case to 2 instances. One in the previous version and one in the current. both instances are linked, so tracking changes is easy. 

So, in summary, BRANCHING Test Cases creates an instance of the test cases on the new version while preserving the original as a baseline. BRANCHING also easily manages and searches through test case versions, by setting up a multiple views to query the data.

Preserving Test Case Base Line as Test Runs

ORCANOS | ALM  uses both test cases and test runs. Test cases define the set of conditions, actions, expected results, and other criteria used to determine if a product component works correctly and meets its traced, specified requirements. Test cases can change over time to reflect functional changes in your product requirements. Such changes need to be identified easily and reflected on the correct baseline, which goes under testing.

Execution Runs on the other hand, are snapshots of test cases that are generated at a milestone in the testing cycle, such as when a new software release is provided by the development team. A test run contains all information from the related test case, in addition to the results of a specific instance of the test.

So while the test case may change in the future to reflect new user logic modifications, the test run steps that were executed in the past, remain in the history of the execution run, and will never change according to most restricted regulation standards for electronic systems, such as 21 CFR Part 11. By saving test runs, managers and auditors can look back on the exact steps followed during testing years, long after the tests have been completed.

A single test case can have one or more related execution runs such as Functional, Progression, Regression, Load and Stability to mention a few; depending on the test variants defined by test parameters selected when test runs are being executed. For example, should an application support multiple browsers, such as Chrome, Edge, and Firefox variants, these variants can be selected when you execute the test, creating a separate test run for each selected variant. The test runs include identical information, except for the test variant value, which indicates the browser used in testing.
orcanos

 

Viewing the Full Change History

As noted, test cases change over the course of the development cycle. Should  you want to view these changes, you may  select a test case, and then click the Execution History tab to view a detailed change report, including who made the change, when it was done, and what was changed.

Change reports display details of content added to and removed from a test case (or any item, for that matter), each time it is saved. ORCANOS | ALM keeps audit logs of changes according to best practices of  regulated design change management. These reports identify the specific changes made to a test case over time. Change reports are ALWAYS turned on and available for both historical item information logging, and detailed audit trail loggings for test cases.

 

orcanos

Once you are in the Change Report window, you will see content which has been added or removed from the test case. You can also view the electronic signature in cases where changes are made and signed (in ORCANOS | ALM 2.0 and later), and you have permission to view the audit log, If there is an attachment, a link to it will be visible.

Reuse Test Cases

Should you want to add test cases that share the same basic information, ORCANOS | ALM saves time by taking the test to the next baseline automatically. You can then decide if you would like to keep it as it is, make changes,  or just make deletions from that next baseline version. There is no need to duplicate an existing test case and then edit the new test case. Simply select the test case from the next baseline version on the product tree module, followed by selecting Edit Test Case by pressing the Edit button.

ORCANOS | ALM gives you the option to link the altered test case with the original test case into a new execution set. You can also specify the traceability between those test cases to a requirement, and any change to already existing traceability will be managed, based on the baseline it has been associated with.

For example, you might create a “Baseline Test Case” on version 1.0 traced to a requirement in 1.0, then you make changes to that test case in version 2.0. ORCANOS | ALM will alert you that there is a suspicious link needing attention. Allowing you to easily identify and manage changes.

Test Case Versioning in ORCANOS - IMG5

BRANCHING test cases also “copies” information you select from the original test case. Besides the results, all other information including attachments, are always included in BRANCHED test cases. The newly BRANCHED test case now has a new baseline for Execution Run that is kept in tandem with the previous version results. In such cases, you can measure the Feature Maturity by looking at the history of the test over executed version, and see that it gets stable. History of the test will be kept through both version 1.0 and 2.0 at the same audit log, as well as file attachments, links, and more, from the original test case.

Test Case Versioning in ORCANOS - IMG6

orcanos

Original Test Case

2016-06-28_13-28-45

Test Case after Branch

2016-06-28_13-29-09

For more information about duplicating test cases, along with step-by-step instructions, see ORCANOS | ALM online help.

Querying Using Views

The ORCANOS | ALM view designer can be used to easily manage and search through different versions of test cases. In the View dialog box, simply select “test case” from the dropdown list, to add specific criteria to the view by selecting the field VERSION, and use the operands to search the data as you wish.

The end result should look something like this:

orcano

You can use this field criteria to identify the test case version for which each test case is valid, and make it visible at a glance in the test case list window. In the example below, you can see test cases and their version, as well as identify whether they were BRANCHED or not. You can also see the traced requirement of that test case.

Test Case Versioning in ORCANOS - IMG9

orcanos

Test Case Versioning in ORCANOS - IMG11

In this example, the user has also displayed the column for Version Baseline Test Case Traceability relations links, enabling you to see which test cases are linked. Clicking on the blue bar links directly to that traced item.

When the 3.0 update is released, ORCANOS | ALM will advance the project, and automatically all test cases from version 1.0 and 2.0 will be available and will be managed separately. Any current test case that does not change, or does not need an update, will keep its original version. If a test case does need an update, the user would add that test case to Execution Run built into version 3.0, without duplicating the test case, Execute the test cases, and it will be marked as valid for 3.0.

Creating a general custom field,  allows you to filter by many other attributes and creates KPI measurement on your overall productivity. ORCANOS | ALM enables email notifications about changes based on product version, enabling field-level security, and more.

Again, for more information about creating custom fields, see ORCANOS | ALM online help.

Folders are another option for managing test case versions in ORCANOS | ALM. Check out the online support and learning resources at www.orcanos.com for more information.

QPack Web – making it work with distributed teams

October 9th, 2014 Posted by ALM 2.0, Collaboration, Distributed development, IEC 62304, Requirements Management, Test Management 0 thoughts on “QPack Web – making it work with distributed teams”

Recently, I get lots of queries regarding “How QPack can help us managing distributed teams?”

Well, QPack has all it takes for managing and control a distributed development project.

In this post I will describe in short what are the main QPack tools that are used for distributed development.

Later on, I will give you our best practice and some tips of how to start and how to make it work.

So,

whether you are a Project manager, product owner, project manager, software manager, tester or developer – you can use QPack collaborative tools and methodology for creating productive, distributed development teams using .

qpack_dashbaord

Web based system

For first, in order to implement a good collaborative environment, QPack web interface should be used, at least for the end users.

QPack Web is HTML5 based, and accessible using any browser and any operating system, thus making it accessible anywhere anytime.

Integrated ALM system with one repository

QPack in it’s nature is an integrated ALM system. QPack suite offers all modules required to manage a project, from market requirements definitions, to system and software requirements, detail design, test plan, test cases and test execution with defect tracking and task management, so every participant in the process has his own interface and everyone shares one central repository.

Full permissions and personalization

In QPack Web admin interface it is very easy to setup user profiles, and admin can decide with just few clicks who will see what and who can do what.

Instant messaging

A unique and integrated instant messaging allows every participant in the process to share his ideas, ask questions and provide information.

the uniqueness of QPack instant messaging is in that every discussion is saved as audit log of the specific work items history (such as customer requirements or a defect). Users can later on go back and track decisions taken. It actually replaces conversations, emails, and uncontrolled documents

Queries, Alerts and notifications

by defining queries and alerts its very easy to track information and get notifications in “Push” mode, where QPack sends alerts containing activities to perform based on predefined rules.

Dashboards

Whether you are a developer, tester, or manager, you can personalize your dashboard accordingly.

You can setup any type of report

 

Congratulations to Argo Medical: received FDA approval in the REWALK using QPack system to produce documents submission

June 28th, 2014 Posted by ALM 2.0, Company, Company News, Customers, FDA, IEC 62304, ISO 13485 0 thoughts on “Congratulations to Argo Medical: received FDA approval in the REWALK using QPack system to produce documents submission”

system allows paralyzed to stand and walk independently; Approval is expected to help the company realize its plans to go public or be sold at a high price

Argo Medical Corporation announced today (Friday) on receiving FDA approval for company’s REWALK system which allows paralyzed to go with it. Certification will be conducted with the help paralyzed in their homes, which until now have only been able rehabilitation centers. According to estimates, is expected to help the company realize certificate programs to its issuance, or alternatively to be sold at a high price. The submission process led the Israeli team in collaboration with the American team using Orcanos QPack medical manages the production of all documents, including changes in content in software validation documents along with Traceability tables automatically generated with non-contact person.

עמית גופר

Amit Goffer

Last March revealed “Kalkalist” Argo Medical intention to go public on NASDAQ at a value of $ 250 million – the value may even be higher if the company will issue shortly.

QPack Medical System is a system for managing development processes and quality for companies and manufacturers of Medical Equipment, containing the largest number of processes in one system integratively. Recently Orcanos released the seventh generation of the system and added two primary processes in Medical device product quality system. One document management system that includes electronic signatures subject to the conditions of 21 CFR Part 11 and the other, customer complaints management system in accordance with ISO 13485 section 4.2. These additions allows Orcanos SMB market also to handle the development of small firms in relation to changes in the process of quality. Also Orcanos added a new key component that enables us to work with external subcontractors and document changes QPack Web which saves time synchronization.

Download QPack cloud system:

Check out “QPack ALM

company, located in Yokneam, founded by Dr. Amit Goffer, four limbs paralyzed himself . The company, established in 2001, currently employs 50 employees in Israel and around the world. The system developed has received numerous awards and was shown at various events over the years, including President Barack Obama during his visit to the country.

Japanese Yaskawa Corporation (YASKAWA Electric) is considered a leading candidate to buy the company. Last year Argo Medical signed the strategic cooperation agreement with the corporation, which invested $ 10 million in the company, and signed her exclusive distribution agreement in Japan and China and the creation of customer service in Singapore, Thailand, Btayewan and South Korea. With investors include Life Sciences Fund also VitaLife Foundation, nitroprusside and Pontifax Fund.

According to reports, Argo has about 30 centers in the world who offer the system, and 200 who were trained to be assisted paralyzed her.

ReWalk is an exoskeleton suit that enables people with disabilities and lower limbs paralyzed stand and walk independently without assistance. Exoskeleton suit battery operated daily prolonged use, allowing the user convenience without having to recharge. ReWalk system is controlled by a computer and motion sensors, and controls movement through subtle changes in center of gravity, mimics natural gait and walking speed provides functional.

Orcanos 6th Medical Event – IEC 62304/62804 New Updates

May 8th, 2013 Posted by Events, IEC 62304, Presentation 0 thoughts on “Orcanos 6th Medical Event – IEC 62304/62804 New Updates”

New Updates on IEC 62304 and IEC 82304 By Sherman Eagles.

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”

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:

IEC 62304 main processes

March 9th, 2011 Posted by IEC 62304 0 thoughts on “IEC 62304 main processes”

IEC 62304 addresses the following main processes:

  • Software development plan
  • Software development
  • Software requirements analysis
  • Software architectural design
  • Software detailed design
  • Software unit implementation and verification
  • Software integration and integration testing
  • Software system testing
  • Software release
  • Software maintenance
  • Software risk management (refers to ISO 14971)
  • Software configuration management
  • Software problem resolution

What standards are required for medical device software?

March 2nd, 2011 Posted by 21 CFR part 820, IEC 62304, ISO 13485, ISO 14971 0 thoughts on “What standards are required for medical device software?”

There are lots of standards, and I sometimes find it confusig, where people dont really know what is the acceptable standard for software lifecycle in medical device, acceptable by the FDA and CE. Some vendors also claim t support specific standards, such as 21CFR 820, which has nothing to do with softwaare lifecycle in specific.

I came to the final conclusion:

The acceptable standard for software lifecycle management is IEC 62304, you can find some data about it in this blog

The ISO 14971 talks about risk management

The 21 CFR part 820 is more or lessthe same as ISO 13485 and they don’t talk about software lifecycle in particular (see this link for reference: http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 ). The software lifecycle is only one part.

The FDA guidelines for software lifecycle managemnt are specified in the General Principles of Software Validation, and they are very hard to understand. Thats why it is recommended to use the IEC 62304 guidelines.

Page 1 of 2
1 2
Orcanos

Contact

8 Tozeret Ha'aretz Street
Tel Aviv, Israel
+972-3-5372561
info@orcanos.com

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