MAN-12 Computational Controls
Manual for computational controls in Ketryx
1. Introduction
This document provides a comprehensive overview of the computational controls implemented in the Ketryx Platform. These controls are designed to ensure the correct execution of Quality System procedures in software development, particularly for medical devices and other regulated industries.
1.1. Purpose
To outline Ketryx Platform's computational controls and their benefits.
To show how these controls align with industry standards like IEC 62304.
To highlight the platform's role in enhancing software development quality assurance.
1.2. Scope
This guide provides an in-depth look at the Ketryx Platform's computational controls across three key levels: task, activity, and process. It covers configuration item controls, module-level controls, release-level controls, and incremental testing capabilities. Each section explores the available controls, their configurability, and their impact on the software development lifecycle, with a focus on enhancing quality assurance and regulatory compliance.
1.3. Document Structure
The content is organized to mirror the Ketryx framework's hierarchy:
Task Level: Configuration item controls
Activity Level: Module controls
Process Level: Release controls
Within each level, we describe the available features, their technical implementation, and examples of their application in maintaining quality assurance standards.
This technical guide is intended for software developers, quality assurance specialists, and system administrators evaluating or using the Ketryx Platform. It assumes familiarity with software development processes and quality management systems in regulated environments.
2. Description of Computational Controls
2.1. Levels of Control
One of the key principles from IEC 62304 that is employed in the design of the Ketryx platform is hierarchy of process. 62304 utilizes the following scheme to categorize different units of work:
Tasks are related and interlinked to make up activities, activities are related and interlinked to make up processes.
This structure is mirrored in the Ketryx framework:
In Ketryx, when a user is performing a task, they are generally working on a configuration item, such as requirement definition, authoring specifications, or executing tests.
When a user is working on an activity, they are generally working at the module level - resolving traceability, performing overall risk management, or creating a test plan.
When users work on the process, they generally work at the release level, seeking to complete the overall cycle successfully.
This document walks through the computational controls available in Ketryx through this hierarchy, starting at the configuration item level.
2.2. Features
2.2.1. Task Level - Configuration item controls
Approval Rules
Each configuration item type may have its own configurable approval rule requiring certain groups to approve an item before it becomes controlled. For example, a requirement item type may have different approvals than a software item specification.
[Supported in Jira] For more complicated workflows, approvals may gate the transition a configuration item from one state to another. For example, requiring approval to transition a CAPA from Open to Planning.
It’s possible to configure whether approvals require Part 11 compliant signatures on the grain of the configuration item type.
Required Fields
Configuration items can be gated from approval if they do not have the required fields filled out. These field sets are configurable and can be applied to custom fields.
[Supported in Jira] For more complicated workflows, approvals may be gate transitioning a configuration item from one state to another. These transitions may also be gated by required fields.
Invalid Items
Invalid items allow granular definitions of field values and status combinations that should block a release. These are paired with human-readable error messages that explain to the user why a particular item is invalid. This is different from approval rules because items can be invalid without passing through an approval process.
For example, to enforce that Anomalies with a Resolution of "Duplicate" have a certain status:
This is a powerful mechanism that can also enforce certain guard rails for the test plan of each release. For example, to enforce that all tests that act as risk controls are included in the test plan:
2.2.2. Activity Level - Module controls
Traceability
Coverage checks can be configured for the RTM, which allows enforcement that trace links have been established between item types. For example - every requirement shall have a specification item that fulfills it. A project team can define as many of these checks as they desire and have engineering controls for the specific V-model that the project team defines.
The traceability matrix also has the capability of configuring warnings and visual indicators based on missing checks along a trace chain to give granular feedback on all the actions that need to be taken to bring a trace into alignment with the QMS requirements. A complete and compliant trace will have a green indicator at the bottom:
Risk Management
Ketryx can enforce different risk models and evaluations on different hazard types. A common application is to have different risk models for hazards of type cybersecurity versus risks of type safety.
It is configurable on the project level how strictly to enforce an association between a specific harm and a severity. It can be a soft association, where the selection of a harm will suggest a severity that can then be changed by a user. It can also be a hard association, where severity and harm are directly linked to each other and cannot be changed.
It is configurable as to how strict selections of hazards and hazardous situations are made. In the defaults, these are open fields that users can populate with arbitrary values. In strict enforcement, these fields can only be selected from specified lists.
Design Verification
Ketryx can enforce a strict order of design verification on a trace-by-trace basis with the Require re-verification of accepted items after change control setting. This setting will require a re-review of any design output of a changed design input. For example, if a requirement is changed, the specification items that fulfill that requirement will be transitioned from closed to resolved - requiring a re-approval to verify that the specifications still fulfill the requirement. This cascades, such that if a specification is re-opened due to the requirement, those test cases that test the changed specification will be transitioned to a state that requires re-approval. It’s important to note that this feature functions at the level of a trace. It will not affect items that are not included in the trace from the originating change. There is further discussion and an example in the Enable incremental testing section below.
Ketryx can enforce that a design output cannot be closed until all of the design inputs are closed with the Require controlled design inputs before a design output can be approved setting. It’s important to note that this feature functions at the level of a trace. It will not affect items that are not included in the trace from the originating design inputs.
Test Management
Each release is required by default to have a test plan for which all of the test cases that are included have been reviewed and approved and all of the test cases have associated passed test executions.
Enabling Require a manual test execution for each effective automated test execution imposes a control that a review and approval cycle on the outputs of an automated test - rather than just a report of the pass / fail status of an automated test.
Enabling Require automated tests to be associated with test cases imposes a control that an automated test must be reported against a documented test case in the system. By default Ketryx is more lenient than this, allowing automated tests to be reported directly against other configuration items, such as specifications and requirements.
Enabling Allow controlled failed test executions relaxes the control that every test in a release's test plan must pass for the release to be completed. This control permits a failing test execution if it has been reviewed and approved.
Enabling Inherit excluded tests will count test executions from previous releases as effective for test cases that are not included in the current release test plan. This allows organizations to show testing coverage from previous releases for features they don’t intend to test in the current release cycle.
Enabling Require test executions after controlled test cases imposes the control that a test execution can only be executed after a test case has been controlled and approved.
Training
Enabling the Require training control enforces that users who have not completed their required training items cannot execute the approval authority of the group that has that training requirement. For example, if a user is in an R&D group and that group is required to read and acknowledge the Quality Manual of the organization to sign off as an approver. If they have not completed the acknowledgment of the Quality Manual, Ketryx will not allow them to sign for the approval and will alert them to the training deficiency.
Milestones
Milestones allow an organization to collect sets of configuration items and documents into a set and can block approvals of other configuration items until the configuration items in the milestones and the milestone itself are approved. This is a powerful feature if an organization seeks to work in a more waterfall fashion. Milestones can also be used with less imposed control, serving as status indicators to the completion of major tasks - such as requirements definition and approval, for example.
2.2.3. Process Level - Release controls
Release Checklist
Note: All of these controls are enabled by default, but can be disabled at the project level to relax certain constraints.
Disabling Require controlled and accepted dependencies allows dependencies managed in the SBOM module to not be reviewed and approved to complete a release.
Disabling Require controlled items allows other configuration items (ex: requirements, specifications) to not be reviewed at the configuration item level to complete a release.
Disabling Require a controlled test plan removes the requirement that a test plan must be defined for a release to complete the release.
Disabling Require generated release documents removes the requirement that design control documents must be generated prior to completing a release.
Disabling Require uploaded build documents removes the requirement that any defined build documents reported via the API must be collected prior to release.
Disabling Require up-to-date release documents removes the requirement that, after release documents have been generated, that they must be updated if any of the underlying configuration items have been updated prior to the completion of a release.
Disabling Require approved release documents removes the requirement that all of the design controls documents must be approved prior to the completion of a release.
Disabling Require full traceability removes the requirement that all of the traceability checks defined on the RTM must pass prior to the completion of a release.
Disabling Require controlled milestones removes the requirement that every milestone defined for the project must be reviewed and approved prior to the completion of a release.
Build and Deployment Management
The approval of a release within Ketryx can be used to gate deployments to certain environments in organizations' CI/CD processes. The primary application of this capability is failing builds that deploy to a production environment if a release is not completed. This provides a strong guarantee that unvalidated software cannot be deployed into production.
2.3. Enabling incremental testing
For the following use case:
I, as a release manager, would like to utilize the testing evidence as long as the underlying clauses that are being tested (requirements, specifications, etc) have not changed. This would allow my teams to not repeat testing unnecessarily.
This is currently possible in the Ketryx system with a combination of the controls:
Require re-verification of accepted items after change control
Require test executions after controlled test cases
To give an illustrative example, consider the following trace that is part of a larger project
The green boxes around each configuration item indicate that it has been reviewed and controlled (a yellow box indicates that the clause is open to editing).
Currently, the trace is ‘complete’. All of the items are controlled, and a test execution satisfies the test case.
A user decides they need to re-open the requirement for some refinement.
Because Require re-verification of accepted items after change control is enabled, the specification and test case items are reopened, as they would need to be re-reviewed to ensure the specification still fulfills the requirement, and the test case still validates the requirement (and verifies the specification, but that is a secondary effect).
Now, as the test case is no longer considered controlled, the Require test executions after controlled test cases kicks in, this would invalidate the current test case and require a re-execution to bring this trace back into alignment with the requirements of the QMS.
The important thing to note is that these mechanisms operate at the level of the trace. This means that if nothing changes on a trace, then the test execution would not need to be re-executed. Tests would only need to be re-executed for those traces where something changed.
This mechanism works with any connected system. So it would work with TestRail defined tests.
As a final note, a side effect of this configuration is the requirement of the re-verification of the items in the trace downstream of the change. In the case above - the re-review of the specification and test case item. This may be undesirable. If that’s the case, it’s a straightforward feature to develop to invalidate a test execution in the event that any configuration item in its trace is changed, without the attendant re-verification steps.
Last updated
