Posts tagged "business requirements"

What is the Traceability Tool For Data Modeling In Medical Device Development?

July 3rd, 2016 Posted by Software Lifecycle Management 0 thoughts on “What is the Traceability Tool For Data Modeling In Medical Device Development?”

Good Development Practices (GDPs) can be defined as the requirement to describe facilities and equipment; to document established procedures (including changes to those procedures and investigations of deviations); and to maintain method development data at the research and development stage. Part of the GDP helps any product development process to expose the affecting changes on the final product delivery. Such could be requirements, risks or customer complaints  of interest for that product. As a Medical device vendor, you need to use the most common practice logic Flow Diagram based on V&V module. It includes requirements, test plan, and risk Management framework. In the diagram below ORCANOS | MEDICAL provides templates and regulatory guidance, with comprehensive traceability table (shown below).

WhatistheTraceabilityDataModelforMedicalDevice_1

 

A typical V&V traceability report characterizes the relationships between those items as a nested relationship diagram.  The following example illustrates those relationships:

WhatistheTraceabilityDataModelforMedicalDevice_2

Product Manufacturing

The report presents the flow of the IEC 62304 from the design phase to RISK and Validation. Such reports can be produced for different initiatives. Another initiative that is vital to your business, is the flow from your company business requirements down to implementation, and the validation of those requirements. Business goals are  achieved by the R&D ability to implement them as they are described in the Market Requirement Document. Typically in a medical device product development process traceability relationships can be found across other aspects of the ISO 13485, such as management of customer complaints (Post Marketing Stage), their RISK assessment, and mitigation by design to those RISKs. More concepts used in the development process such as Standards integration (CE, FDA guidance, ISO, etc.) can be produced as documented evidence in  your next audit.

Other Artifacts

The ORCANOS | MEDICAL system builds your  entire Technical File or 510K submission files electronically, and maintains all necessary traceability between documents traceable artifacts which  come from the requirements specified by your QMS system. This  powerful tool is the way ancillary traceable artifacts are referenced throughout the product lifecycle.

One example is the medical device Essential Requirements statement. While it may be convenient to continue using regular Office tools such as Excel or Word, the complexities that come with the software is well known, especially when it becomes necessary for one document to reference another. Using process automation tools such as ORCANOS | MEDICAL, ensures  consistency of traceability wherever it is used. The link between Essential Requirements and product Requirements are among evidence documents needed in your technical file or any other common submission. This ensures the ability to establish against any point where a standard requirement describe in simple text is used, what is the impact on items implementing those requirements in the product/process development. The ORCANOS | MEDICAL system will  populate  the relevant information for all  documents or people.

 

WhatistheTraceabilityDataModelforMedicalDevice_3

 

If we talk some more about Risk Management, we may find that it is not difficult to describe and understand. Here is a simple description of the RISK management logic, We have hazardous situations that lead to harms. These hazardous situations should be documented, in order to mitigate and  control an outcome to make the use of a device predictable and safe. However, the implementation of such a system is complicated by a variety of factors:

  1. Cross reference between many-to-many various system components
  2. Reusable data cross components
  3. Regulatory expectations

For this reason ORCANOS | MEDICAL software is offered as a means to organizing the various components of the system.

How To Organize Your Data

First, the data should be organized according to how it will be reviewed by internal/external auditors as well by the way it needs to be produced by the system out to official documents. After release of a product to the field which is referenced as post market, surveillance will evaluate the product on the basis of the user harm, the user hazard, and the number or percentage of field complaints occurrences. Our data fields should directly mirror the information returned for easy comparison (using traceability back to RISK), and respond to issues identified in the field. We should be able to track the occurrence of a harm in the field, and directly compare it with the risk management process. This will allow us to immediately evaluate whether the RPN factor (ISO 14971) used to determine the frequency of hazardous situation results in a harm, is correct, or whether the probability of the hazardous situation occurring has been improperly assessed.

On that matter, ORCANOS | MEDICAL provides a post marketing surveillance system to collect customer experience and customer complaints, which can be linked to the RISK management artifacts on the same system. This is part of the combined solution ORCANOS | MEDICAL provides for all 3 sources of data: R&D QUALITY & REGULATION

WhatistheTraceabilityDataModelforMedicalDevice_4

 

WhatistheTraceabilityDataModelforMedicalDevice_5

 

Secondly, the data fields should represent common terminology. Regulatory bodies have defined what is meant by a hazard, or hazardous situation. We should build the regulated terminology into our model to provide a system that helps auditors better understand our intent without additional explanation.

Thirdly, work items should be organized in such a way as to minimize linking complexity. It is possible to provide so many degrees of freedom in the system, that the flow of information becomes difficult to follow. This may result in some difficulty when training employees on the system, and explaining to regulatory authorities.

More about the flow diagram for definition of risk can be found in ISO 14971:2009 and required for compliance with both the United States and European medical device approval systems.

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.

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