MAN-01 Ketryx Lifecycle Management
Manual for the usage of the Ketryx Platform
1. Introduction
1.1. Purpose
The purpose of this manual is to explain the ongoing usage and operations of the Ketryx Platform, a lifecycle management system built to streamline high-quality software development and support FDA software compliance and compliance with standards such as ISO 13485, IEC 62304, and ISO 14971, among others.
1.2. Scope
The scope of this manual is the complete usage of the Ketryx Platform. This includes a description of the Ketryx Framework, a logical framework of rules and entities that are implemented within the Ketryx Platform software system.
1.3. Referenced Documents
ISO 13485
IEC 62304
ISO 14971
1.4. Definitions and Acronyms
For the purposes of this document, the terms and definitions given in U.S. QSR (21 CFR Part 820), ISO 13485, and IEC 62304:2006-AMD1 apply. Where contradictory, IEC 62304 and ISO 13485 prevail.
ALM: Application Lifecycle Management
QMS: Quality Management System
QS: Quality System
EDMS: Electronic Data Management System
Activity: a set of one or more interrelated or interacting Tasks
Configuration Item (CI): an entity that can be uniquely identified at a given reference point
Deliverable: required result or output (includes documentation) of an Activity or Task
Task: a single piece of work that needs to be done
Effective/Controlled Configuration Item: a Configuration Item that is in active use by the system for a given version
Traceability: the degree to which a relationship can be established between two or more products of the development Process
Process: a set of interrelated or interacting Activities that transform inputs into outputs
Verification: confirmation through the provision of objective evidence that specified requirements have been fulfilled
Project: a self-contained (sub) system or service with its own verification, validation and release lifecycle, and its own access control and approval rules. Each project defines its own versions. Projects might contain references to other (“sub” or “service”) projects. This is the primary “scoping construct” in Ketryx.
System: integrated composite consisting of one or more of the processes, hardware, software, facilities, and people, that provide a capability to satisfy a stated need or objective.
Product: a version of a system validated to a test case that meets certain requirements and is provided to users
Sub-system: integrated collection of software items or hardware items organized to accomplish a specific function or set of functions
Service: a self-contained and validated system with specific predefined interface requirements
Organization: an organization or organizational unit (e.g., Center of Excellence, Business Unit), managing its own members and projects. Each project is owned by one organization
Member: a user within an Organization. Each Member can be either an owner or a regular organization member.
Group: a group of Members defined in an Organization.
COTS: Commercial Off-The-Shelf
MFA: multi-factor authentication is a security method that requires multiple types of credentials to verify identity, adding an extra layer of protection. Ketryx supports two MFA methods: WebAuthn (Web Authentication) and OTP (One Time Password).
Electronic signature: method of authentication that is used to sign electronic records or documents. It serves as a means to indicate the individual's intent to approve, authenticate, or authorize the content of an electronic record. 21 CFR Part 11 defines it as a "means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual's handwritten signature." Organizations can require multi-factor authentication (MFA) for electronic signatures in Ketryx, to ensure compliance with 21 CFR Part 11.
1.5. Responsibility and Authority
The Organization shall define responsibilities by assigning Members to Groups. Authority over configuration items is provided to Members and Groups through the project’s Approval Rules, which consist of Approval Steps. These steps can be configured to require approval from either Groups or Members. By default, Ketryx is configured with approval steps based solely on Groups. The approval rules can be found under the project Settings if the Member has permission to view that information. To modify the approval rules and, as a result, the authority of your project’s QMS, you would need to have edit permissions for Approval Rules.
Ketryx comes with sensible default configurations that can cover many modern software development workflows. For responsibility and authority, Ketryx has five default groups and a set of default approval rules. Ketryx can be configured to add groups and support additional work instructions. The default groups are:
Product Managers
R&D Leads
Developers
Quality Managers
Quality Control
It is considered best practice to have members assigned to only one group to ensure division of responsibility. Any abstract approval structure, whether based on groups or users, can be created in Ketryx. Organization owners can create additional groups and define permissions for those who can manage groups and approval steps.
Further information on how to configure a project’s Approval Rules can be found in MAN-11 Approval Rules.
2. Ketryx
2.1. Ketryx Framework
The Ketryx Framework is an object-based, gated, risk-based product development framework for validated application lifecycle management. Users, called Members within an Organization, work collaboratively to create products, set requirements, and collect evidence that those requirements are met through the IT systems used throughout the product lifecycle. Members and Organizations are examples of two types of entities in Ketryx that can interact in a pre-specified, structured manner.
In Ketryx, Members use Configuration Items (CI) to build Systems, Sub-Systems, and Services. CIs are the atoms from which systems are built and are managed in various tools native to the given task (requirement management, source control, etc.). Each System, Sub-System, and Service is a CI, and it is managed in Ketryx as a Project. Projects can interface with other projects to create the structure needed for complex system engineering.
Members have authority and permission over CIs and their lifecycle, depending on each project’s Approval Rules. Some Members can author, review, and approve a configuration item for it to become controlled and effective. Others might only have permission to view a Project. If a Group that a Member is a part of has assigned training, Members must perform that training, or they will not be able to perform actions (i.e., approvals) as part of the Group. Specific Groups and/or Members are required to approve the release of the validated product (i.e., project version). Further details on the framework and the different entities (i.e., objects) that exist in it are provided in the following sections.
2.1.1. Entities
Ketryx has six different types of entities that interact in pre-defined ways to create the type of structure and traceability safety-critical applications require. The following are the types of entities in Ketryx, and the diagram below shows how they interact:
Organization
An Organization consists of Members who work together to create products. Each Member must have a role as either an owner or a regular member of the organization. An owner can add other members to the organization and potentially promote them to owners.
Project
A self-contained Subsystem, System, or Service and related activities that together create a product. Each Project has its own verification, validation, and release lifecycle, its own access control and approval rules, and its own versions. A project is typically done by a Product Team within an organization.
Member
Individuals that are part of the Organization.
Group
A set of users within an Organization that has authority/permissions.
Permission
Permissions control what a user (or user group) can do within an organization or project.
Configuration Item
An entity that can be uniquely identified at a given reference point
2.1.2. Configuration Items
Configuration Items can be combined within Projects to make any arbitrary System, Sub-system, or Service. CIs can govern all aspects of the Total Product Life Cycle (TPLC) and, through the Ketryx Platform, can be used to create evidence for audit or submission. Each controlled configuration item represents an approved record, and a validated system can only be created with controlled configuration items. Evidence of this controlled state can be seen in each release’s electronically signed documentation.
The following Configuration Items are available in Ketryx, each with its own Work Instruction.
Requirement
Software Item Spec
Task
Test Case
Test Execution
Anomaly
Complaint
Change Request
CAPA
Risk
Hardware Item Spec
Specification of a hardware item, similar to a Software Item Spec.
Software Dependency
Software dependencies are managed through Ketryx Software Supply Chain Management: Software Dependencies.
Cloud Dependency
Cloud dependencies are managed through Ketryx Software Supply Chain Management: Cloud Dependencies.
Test Plan
A set of Test Cases required to release a Version. By default, all Test Cases within the same Project are included in a Version’s Test Plan.
Version
A release of a validated product. Approval rules for versions also apply to release documents associated with a version.
Configuration Items are how members build validated systems. They utilize configuration items to construct, validate and perform change control or systems, resulting in validated products. Each configuration item represents a task or task phase, with multiple representing a series of tasks, also known as an activity.
Members perform tasks as part of the lifecycle activities of Projects. Projects can be nested within each other to form any arbitrary complex system of systems. Generally, a project can represent a System, Sub-system, or Service, which can be connected. Systems can then be validated and verified (V&V) through a Test Plan. An example of a product lifecycle that can be implemented in Ketryx is given below. The Test Plan would indicate which Test Cases need to be performed (through a Test Execution CI) and passed before product approval by the PLT.
If instead of a V-model, we look at the pre-market lifecycle sequentially, we get the following diagram, which describes the lifecycle process requested in ISO/IEC 62304. In section 5 of this manual, we will review this diagram (and section 5 of ISO/IEC 62304) in detail.
Looking at it beside the earlier lifecycle process diagram shows how the Ketryx Platform allows the development of products developed under the Ketryx Framework.
Configuration Item States
Configuration items managed through issue/task management tools (e.g., Jira) have four native states, described below. Additional states can be added.
Open - The item is proposed.
In Progress - The item proposal is being drafted into a final proposal. The ticket can be reviewed and edited.
Resolved - The ticket is in an immutable state and is pending review and signatures from relevant approval steps.
Closed - The ticket is closed, and no further actions are needed. For a design ticket, this state would mean the design is verified.
2.1.3. Components
The framework focuses on three components:
Risk Management: systematic application of management policies, procedures, and practices to the tasks of analyzing, evaluating, controlling, and monitoring
Configuration Management: Configuration Management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life
Agile Software Development: Iterative and flexible approach to software development, focusing on building smaller pieces of functionality.
These three components are integrated into the Ketryx Framework, Ketryx Platform, and the way Members build validated products. Each is discussed in detail later in this manual.
2.2. Ketryx Platform
The Ketryx Platform (“Ketryx”) is a connected application lifecycle management platform that automates the Ketryx Framework. It allows teams to use portions of the Ketryx Framework relevant to their quality system and day-to-day activities.
Ketryx allows Members to easily integrate a risk-based approach into their software development tooling and centralize their work from a single source of truth. It allows teams to develop software across those tools with full traceability and visibility in a 21 CFR Part 11 validated system.
Ketryx is built on three principles:
End-to-end traceability: allowing users to understand how everything is connected
Compliant-by-design: guiding users on regulated software development
Minimalist but connected: easy to learn and build in
The Ketryx Platform consists of several interconnected modules and 3rd-party integrations, such as Jira and Git. These allow users to define requirements and enforce them across IT tools, creating complete and auditable configuration items. These can demonstrate compliance with the Total Product Life Cycle approach that is continuously recorded, viewed, used, and audited in Ketryx.
Ketryx supports the following common control use cases, with additional ones possible to add:
Design Controls: Record and manage requirements, specifications, and other design control items in Jira.
Configuration Management Controls: Record your source code, build, distribution and deployment directly from your source code management and cloud provider.
Process Controls: Following Compliant-by-Design (CbD) can be provenly enforced across IT systems. Evidence can be generated and collected to show that Design Controls have been met. Design Controls can be recorded and managed in Jira.
Cybersecurity Controls: Integrate cybersecurity requirements directly into your product, and scan your code daily for application vulnerabilities and software supply chain vulnerabilities.
Release Control: For applications created and managed in Ketryx, releases are carefully managed through a gated approval compliant with relevant quality assurance standards.
As described by the Ketryx Framework, Ketryx has 16 entities called Configuration Item(s) (CIs). Together they can represent the Total Product Life Cycle of any arbitrary system.
Ketryx easily connects to other systems providing users with a seamless, traceable experience, including guided workflows and evidence generation. The following systems are supported in Ketryx.
Source Code Repository: Any Git repository works with Ketryx. Specific advanced source code management tools and evidence collection modules currently only work with GitHub.
Task/Issue Management: Ketryx connects to Jira through an Atlassian Marketplace app. Once installed and connected to a Ketryx Organization, Projects created in Ketryx can be connected to Jira projects. This will create Ketryx-specific workflows, issue types, and screens in Jira and automatically configure the connected Jira project with them (unless it contains issues already, in which case the initial configuration is more manual). The Ketryx-specific Jira issue types correspond to Configuration Items 1 through 11, while Software Dependencies, Cloud Dependencies, Test Plans, Versions, and Documents are primarily managed nativity in Ketryx.
Cloud Deployment: Ketryx currently supports AWS as a native integration. You can still use any other feature of Ketryx and record evidence as discussed.
2.3. Related Manuals
2.4. Related Work Instructions
3. Risk Management
Associated Deliverable: Risk Management File, Risk Control Matrix, Risk Matrix, V&V Report
Tooling: Risk Management Screen, Risk Controls Screen, Risk Configuration Item
Members can conduct project-level and configuration item-level risk analysis. Risks in Ketryx can be used to follow an ISO 14971-like process and are based on Hazardous Situations. The focus should be on what can happen and how to prevent harm to the patient. Risk management can be done continuously in Ketryx for each successive version and each system individually and in a centralized fashion.
Each risk is managed individually as a Risk configuration item. As a whole, risks can be managed through the manufacturer’s risk management process. While the Ketryx framework provides tools and automation for risk management, management of product and none product risk is the sole responsibility of the finished product manufacturers, which should have an approved risk management plan.
For a more in-depth guide to risk management in Ketryx, please refer to manual MAN-08 Risk Management.
4. Configuration Management
Deliverable: Design Control documents (SRS, SDS, etc.), Software Bill of Materials, Part 11 Verification Report
Tooling: Software Dependency Screen, Cloud Configuration Report, Release Configuration Item Screen, Electronic Document Management System (EDMS)
4.1. QMS Configuration Management
All QMS documents can be stored in the Ketryx Electronic Data Management System (EDMS).
4.2. Design Control Configuration Management
4.2.1. Design Control Artifacts
Design controls artifacts can be found and tracked in Ketryx through several screens and files. Relevant screens include
the Requirements traceability matrix screen,
the Architecture diagram screen,
the Risk management screen,
the Test management screen, and
the Item records screen.
Design control artifacts that can be exported or downloaded directly can be found in the section on Records and Artifacts.
To become controlled, each design control configuration item must undergo a design verification step that can be electronically signed. This is the design verification activity for each configuration item, which is done according to the configuration item’s pre-defined Approval Rule.
4.2.2. Software Supply Chain
Configuration management for the application software supply chain, including open source, cloud, COTS software, and other dependencies, is further explained in the Ketryx Software Supply Chain Configuration Management Manual.
4.3. Change Management
Ketryx takes a risk-based approach to change management. The default system configuration supports three tiers for change management: the item level change control, the structured change control using the Change Request CI, and the structured action using the CAPA CI.
The three risk-based change control levels provide users the flexibility and structure needed to perform change management in large-scale software applications. The exact usage of these depends on your organization and the context of the product you are building.
Item level change control. Completed via the configuration item's native record. This is further discussed in each item’s Work Instruction.
For Jira: change the status from open to In Progress, Resolved, and Closed
For Git:
software item (i.e., source code): completed via a merge request
software dependency information record (SOUP record): completed via Ketryx; see MAN-03 Supply Chain Management: Software Dependencies
Structured change control using the Change Request CI. Create a Change Request issue in Jira and follow the tasks described in WI-08 Change Request.
Structured action using the CAPA CI. Create a CAPA item in Jira and follow WI-09 CAPA to perform an action that can result in change control.
Together these three levels of change management, the configuration item level, the Change Request level, and the Action/CAPA level, can allow users to conduct various complex change management activities, which can be used to capture all the information required by the strictest safety-critical industry requirements.
5. Application Lifecycle Management
5.1. Software Development Process
In Ketryx, software development is part of a gated product development process, with each gate having milestones and deliverables.
When building safety-critical systems across some industries and jurisdictions, it is important to ensure that the design inputs are fully defined by the design output (i.e., realized in/by the design output). As a result, before system validation, it is necessary to review and approve design-related items and the complete system sequentially, starting at the initial requirements and moving toward the final product technical requirements. This waterfall-like approach is supported by Ketryx’s gated approach while still allowing users to develop software using a variety of development methodologies, including agile-based ones. This is done by enforcing structure for deliverables and the design control management process as part of the release process.
To release software in Ketryx, validation activities must be performed as described in each release’s Test Plan. All Configuration Items that are part of the release must be placed under change control (unless they are unresolved anomalies), the software must be validated per the Test Plan, and the artifacts listed in section 7 of this manual must be generated, reviewed, and approved. Only then can the Groups relevant for Version approval review, approve, and release the software. The below figure notes the software development activities and their deliverables, as well as the audit activities Ketryx can support to ensure needed activities are performed. Further detail on the software release process is provided later in this manual and can also be found in MAN-02 Software Release Process.
Once the software is released and maintenance is required, a complementary process is used.
5.2. Default Configuration
While many aspects of Ketryx can be modified based on a company’s quality system and business activities, there are sensible default configurations built into Ketryx. These include the groups and approval rules for an organization and project, respectively.
5.2.1. Default Groups
At the core of Ketryx are the groups that different system users can be a member of. These groups represent the responsibilities users have on their journey to create validated applications.
The following Groups are defined by default:
R&D Leads
Group Description: Leads the development of software products and makes the technical decisions about the product. Confirms that specifications and the application meet the requirements.
Product Managers
Group Description: Leads product development, defines requirements and deals with complaints. Confirms that the application meets users' requirements.
Quality Managers
Group Description: Leads all quality assurance and quality activities and writes and approves tests. Confirms that the product and the company processes comply with relevant regulations.
Developers
Group Description: Implements specifications into working applications and writes unit tests.
Quality Control
Group Description: Writes and executes tests. Tests implementations and confirms that they meet test case acceptance criteria and processes complaints.
5.2.2. Default Approval Rules
By default, the following Approval Steps are defined for configuration items of the respective type. Each Approval Step is based on one of the default Groups, and at least one approval is required for each step. Unless otherwise noted, items of the respective type have an Item Assignee who also needs to approve. These default Approval Rules/Steps can be changed by a user with the proper permissions in the Approval rules page under a project's Settings tab.
Requirement: R&D Leads, Quality Managers, Product Managers
Software Item Spec: R&D Leads, Quality Managers
Task: none (only the Item Assignee needs to approve)
Test Case: R&D Leads, Quality Managers, Quality Control
Test Execution: Quality Managers
Anomaly: R&D Leads, Quality Managers
Complaint: R&D Leads, Quality Managers, Product Managers
Change Request: R&D Leads, Quality Managers
CAPA: R&D Leads, Quality Managers, Product Managers
Risk: R&D Leads, Quality Managers
Hardware Item Spec: : R&D Leads, Quality Managers
Dependency: R&D Leads, Quality Managers (no Item Assignee)
Test Plan: R&D Leads, Quality Managers (no Item Assignee)
Version: R&D Leads, Quality Managers, Product Managers (no Item Assignee)
Document: R&D Leads, Quality Managers, Product Managers (no Item Assignee)
Further information on how to configure a project’s Approval Rules can be found in MAN-11 Approval Rules.
5.3. Processes, Tasks, Items, and Members
The Ketryx Platform facilitates product creation, management, and retirement. The Ketryx Framework is a set of rules that govern how processes, activities, and tasks can be performed on Items by Members.
Each configuration item represents the abstract notion of the system component, with each version of it a record of that configuration item. Each approval process of an item involves performing all the tasks required by that configuration item’s work instruction, which checks Ketryx’s Rule Engine and creates a controlled record. Only Ketryx can change the state of an Item to Closed by checking with Ketryx’s Rule Engine, which determines if that Item’s current attributes satisfy its description in the Quality System Format. Each Closed record is then stored in Ketryx.
The creation of a Requirement, its drafting, and approval constitutes an activity. Specifically, it is a Design Control activity that ensures requirements are developed, verified, and approved in a controlled and documented manner.
The relationship between processes, activities, and tasks is shown in the diagram below. A process is a set of integrated activities that transform inputs into outputs. An activity is a set of integrated tasks. Generally, Ketryx configuration items are tasks or activities.
Throughout different lifecycle processes, manufacturers use configuration items to manage the tasks required to create a validated system. As mentioned earlier, each configuration item has four states: Open, In Progress, Resolved, and Closed. Members must conduct tasks to move Items between the four states. For a requirement, for example, to move from Resolved to Closed, all the selected approval steps must verify the design (design verification).
For an Item to be an effective configuration item in a given Version, it must be Closed, and the Version must match its version range, as specified by the fields Introduced in version and (for long-lived item types) Obsolete in version. There are generally two categories of configuration items in Ketryx:
Long-lived item types have both an Introduced in version (the first version they are effective in, inclusive) and an Obsolete in version field (the first version they are not effective in, exclusive). These include Anomalies, Configuration Items, Requirements, Risks, Software Item Specs, Hardware Item Specs, and Test Cases. If the Introduced in version is not explicitly defined, these items are assumed to be in the first version. If Obsolete in version is not explicitly defined, these items are assumed to be in every subsequent version.
Point-wise item types only have an Introduced in version field, which ties them to the specific Version they are effective in. These include CAPAs, Change Requests, Complaints, Test Executions, and Tasks.
Note that, for Anomalies, Introduced in version denotes the first version they are known to affect, while Obsolete in version denotes the version they are expected to be resolved in.
Records of items that are deleted in Jira are still kept in Ketryx. A record that marks the deletion is created in Ketryx, which is essentially treated like an obsolete item w.r.t. release management. If the item has been in a controlled state before, the deletion marker needs to be approved (in Ketryx) for the deletion to be considered controlled, i.e. it starts out in the Resolved state; otherwise (if the item has only been in a draft state), the deletion is considered controlled right away, i.e. it is immediately Closed.
5.4. Versions and Releases
There are three different types of releases in Ketryx:
A full release incorporates all items in their current state. For Jira-based items, this is based on the information you currently see on the Jira issue.
A patch release inherits the state of each long-lived item from its baseline version, while only for items that are explicitly marked as introduced or obsolete in the patch release (based on its version number), their current (controlled) state is incorporated.
A scoped version also incorporates only specific changes, similarly to a patch release. But instead of opting into changes based on a version number, items matching a certain KQL filter are considered in scope for change. In addition, certain items related to any matching items can be incorporated as well, including affected or new items of Change Requests and CAPAs, affected and resolving items of Anomalies, affected items of Complaints, and risk control measures of Risks.
Patch releases and scoped versions can be used to release small, incremental changes to certain items without being impacted by modifications to other items that might happen in parallel. Scoped versions can also be created based on a selection of items to include in the scope.
The baseline version of each release is determined based on its version number: The latest released version preceding the given version is considered the baseline. By default, Ketryx looks for a SemVer-compatible version number within a version's name to derive its version number. This can be customized using advanced setting Version number pattern, and in each version's settings.
Depending on the configured release controls, a version can only be released if all included items are in a controlled state.
Wherever a version can be selected (e.g., to filter items), the Current state that can usually as well, which represents the current "draft" of design controls. This includes all items that are not marked as obsolete in any version (regardless of when they were introduced). Jira-based items on Current show the current content as you would see in Jira. Git-based items such as SOUP dependencies on Current are derived from the primary analyzed branch or tag (typically main or master), as opposed to the version-specific release ref pattern (such as a v1.0 tag), configured for each repository in the project settings.
5.5. Building Products
Building validated systems that can turn into products that serve safety-critical functions is a complex, detailed, and challenging endeavor. Ketryx is built to reduce the complexity and cognitive load of building such products, allowing teams to focus on what matters most.
The sections provided below are simplifications of the activities needed to produce validated systems in different industries and jurisdictions. It is expected that the company building the system/product will have the knowledge, resources, and capabilities to build such a system. As a result, the below is only the explanation of Ketryx functions related to these activities and not a description of all the necessary activities.
Additional details about releasing software in Ketryx can be found in MAN-02 Software Release Process.
5.5.1. Software Development Planning
Deliverable: Risk Management File draft
Once a new product is decided on, a project needs to be created to govern the system(s) that make up that project. As part of this process, a Product Leadership Team (PLT) shall be appointed, consisting of a Member of each of the following Groups:
Product Management
R&D Leads
Quality Management
Following the formation of the PLT, the project should start. The software development process will consist of the steps described in Figure 2. At each phase below, the activities listed will be conducted. The deliverables mentioned at the beginning of each phase can be generated, reviewed, and stored in the Ketryx Platform.
5.5.2. Software Requirements Analysis
Deliverable: System Requirement Specification
Tooling: Requirement Traceability Matrix
Members create requirements that can describe a wide variety of systems, environments, contexts, and intended uses. Each requirement is captured in a Requirement type configuration item.
Requirements can be defined throughout the software development lifecycle but must be approved and under change control before any software verification and validation activities begin. Requirements can be developed and managed in the connected issue/task management platform.
Further details on the Requirement configuration item can be found in WI-01 Requirement.
5.5.3. Software Architecture Design
Deliverable: Software Design Structure Matrix, Software Design Architecture Diagram, Software Item Specification configuration item
Tooling: Architecture Module
Members realize requirements into software architecture. This can be done by creating Software Item type configuration items that fulfill the requirements and are combined together to perform different tasks and provide required features and functionalities.
Software Architecture can be defined through the software development lifecycle but must be approved and under change control before any verification and validation activities. Software architecture is defined through the Software Item Specification configuration item, and is developed and managed in the connected issue/task management platform.
Further details on the Software Item Specification configuration item can be found in WI-02 Software Item Specification.
5.5.4. Software Detailed Design
Deliverable: Software Design Specification, Software Item Specification configuration item
The detailed software architecture design (i.e., the detailed design) is developed using the Software Item Specification configuration item and is developed and managed in the connected issue/task management platform.
Further details on the Software Item Specification configuration item can be found in WI-02 Software Item Specification.
5.5.5. Software Unit Implementation and Verification
Deliverable: Code Change Review report, Testing report, Test Plan, SOUP Dependencies report
Tooling: Items screen with filter for specifications, Task, and Test Case configuration items
Software Items (i.e., blocks of code, units, modules, systems) are implemented using the Task configuration item. Tasks are created as units of work, to be assigned to a Member. For each Task, the Implemented items field shall contain which Software Item Specification or Requirement needs to be implemented during this Task. When a merge request is created, the Task item ID should be mentioned in the merge request description to create traceability between the specific merge request and the Task. When a merge request is not related to a particular Task, it may also reference the implemented Software Item Specification, Requirement, Anomaly, or other relevant configuration items directly.
Unit testing, module testing, and system testing are governed by the Test Case and Test Execution configuration items. Before the beginning of any verification and validation activities, a Test Plan can be created to define which Test Cases will be executed as part of the release. Note that if no Test Plan is configured, it is assumed that all Test Cases assigned to any CI in the release will be executed. At least all design endpoints (Requirements and Software Item Specifications with no children) will be executed.
Tasks, Test Cases, and Test Executions are developed and managed in the connected issue/task management platform. Further details on the Task, Test Case, and Test Execution configuration items can be found in WI-03 Task, WI-04 Test Case, and WI-05 Test Execution, respectively.
5.5.6. Software Integration and Integration Testing
Deliverable: Verification and Validation Testing Report
Tooling: Testing Module
Software integration and integration testing can be performed using the same functionality described in the previous section. Further details on testing can be found in WI-04 Test Case, and WI-05 Test Execution.
5.5.7. Software System Testing
Deliverable: Verification and Validation Testing Report
Tooling: Testing Module
Software system testing can be performed using the same functionality described in the previous section. Further details on testing can be found in WI-04 Test Case, and WI-05 Test Execution.
5.5.8. Software Release
Software release should be conducted for each new product version. All configuration items should be placed under change control and approved. Once unit, module, and system testing are performed, all unresolved anomalies should be documented, with their Rationale for deferring resolution field filled in.
The release can only be approved if all configuration items are controlled, required records, deliverables, and artifacts have been generated and approved, and the PLT approves the release. For further information, please refer to MAN-02 Software Release Process.
5.6. Maintaining Products
At the core of Ketryx and safety-critical software regulations is the concept of change management and maintenance. While change management is addressed in earlier sections of this manual, due to its criticality to validated systems, it is again reviewed here in the context of maintenance.
Maintenance is a core part of safety-critical regulatory requirements and is commonly identified as a source of adverse events and harm. As a result, Ketryx requires that maintenance be performed in a controlled manner, using a risk-based approach through traceable configuration items. The main configuration items used as part of maintenance activities are:
Complaint
Anomaly
Change Request
Corrective And Preventative Action (CAPA)
Combined with Ketryx’s deep integration with source code, cloud, and task management systems, these four configuration items provide powerful tools for change management in complex validated systems, like cloud-based, data-driven medical software and robotics systems.
Typically, a Complaint can lead to one or more Anomalies. As part of each Anomaly activity, a problem report is documented. This problem report might lead to a Change Request or CAPA. These can get implemented across the product (e.g., source code), design controls, and the QMS through additional configuration items, like Tasks or Requirements.
Software Maintenance Planning
Software maintenance will be done on a version basis, with internal and external information and feedback leading to maintenance and modifications in the validated system.
Software maintenance (i.e., software change management) can be done on three tiers:
Configuration Item Level
Structured Change Control through a Change Request configuration item
Structured Action through a CAPA configuration item
Software maintenance can happen as a result of a wide range of factors. Additional features (i.e., requirements), also known as enhancements, maintenance to existing code, or as a response to external product feedback or adverse events. Among many things, the reason for change and approval of change depends on the intended use, the use environment, and the quality system of the system manufacturer or user. The decision to implement a change can be a result of multiple factors, for example, a desire to mitigate a source of adverse events (i.e., harm), to enhance the system with new functionality, or to correct a design flaw.
While Ketryx can be used to perform change management, the system manufacturer still must utilize their software maintenance plan for their intended use and use Ketryx’s different tools to implement the change.
5.6.1. Problem and Modification Analysis
Deliverable: Release notes, Anomaly configuration item record
In Ketryx, changes can result from external factors (e.g., customer feedback, adverse events, etc.) or internal factors (e.g., internal feedback, failed testing, etc.). These can be captured using different configuration items, most commonly the Complaint and Anomaly, but in some cases (e.g., enhancements) as a Requirement. As a result of software problems, modifications will be implemented to mitigate and, if possible, eliminate the problem. While the source of the problem can dramatically affect its criticality and priority, the process for modification is generally the same.
External problem reports will be recorded using Complaints, internal problem reports can be recorded using Anomalies. If a problem starts as a Complaint an Anomaly should be created to resolve that Complaint.
For each Anomaly a root cause investigation should be conducted. Once the root cause of the problem is discovered, a Change Request(s) or CAPA shall be created.
Following the Change Request or CAPA, Members shall modify different configuration items.
As needed, Tasks will be created for required source code modification.
Periodically, modifications should be reviewed.
Post-Market Surveillance
Deliverable: Complaint records in Ketryx and other change-related CI records
Tooling: Complaint configuration item
Post Market Surveillance (PMS) is the process of recording, investigating, mitigating, and responding to feedback and information about products in the market. Depending on your quality system and process, this might take various forms.
In Ketryx, the PMS can be performed using the Complaint configuration item and other maintenance and change-related activities. The generic process could involve:
Recording the product feedback or adverse event using the Complaint configuration item
Depending on the type of complaint, create one or more Anomaly type configuration items related to the complaint and investigate the root cause(s) of the anomaly(s).
Utilize a risk-based change control activity to mitigate the anomaly. This would usually be done through a Change Request or CAPA configuration item.
The specific application of Ketryx tools for PMS depends on the manufacturer’s quality system.
Anomalies and Problem Reports
Anomalies (and other deviation types) and problem reports are managed as part of the Anomaly configuration item. This configuration item contains fields to both report and analyze the anomaly, as well as the underlying problem, root cause, and potential solution.
Further details on the Requirement configuration item can be found in WI-06 Anomaly.
5.6.2. Modification Implementation
After modifications have been implemented, each change request can be verified using a Test Case to show the change resolved the root cause.
5.7. Systems of Systems
Ketryx can be used to manage a System of Systems by structuring work into several projects and creating references across those projects.
5.7.1. Cross-Project References
Before items from one project can cross-reference items in another project, the referenced project (the "target" of the relation) needs to be added in the References settings of the referencing project (the "source" of the relation). Each reference can define a particular set of referencable and incorporated items and give fine-grained control on what items are available to the referencing project.
The following sections will outline the general concepts of the referencable space and incorporated pool, including the configuration via different selection modes.
5.7.1.1. Incorporated and Referenceable items
A project reference differentiates between a set of incorporated and referenceable items:
The referenceable items represent the space of items that can be used as a reference within the referencing project
Referenceable items will be selectable as a relation within Ketryx and other third party systems (e.g., Jira)
The referenceable space also includes all items that belong to the referencing project
Referenceable items will not show up on the All items page
The incorporated items represent the pool of items that are listed and accessible via the All items page in the referencing project
Items within this pool are treated as if they would be part of the referencing project and will show up in all parts of the Ketryx app (Risk management, Test management, Traceability, etc.) and also be rendered in related evidence documents
Incorporated cross-referenced items are still complying to the same approval rules and risk configuration settings of the project they are primarily contained in
In the case cross-referenced Test Cases, the test management system will consider all incorporated Test Executions (of the referencing project as well as the referenced project) to calculate the latest effective Test Execution
In regular system-of-a-system setups, the referenceable space is commonly defined as a superset of incorporated items, but depending on the system's needs, it is also possible to define arbitrary sets based on KQL filters.
The project reference may be configured via two different configuration modes:
Filter-based selection of items in referenced projects: This mode allows defining a fine-grained scope of incorporated and referenceable items via Simplified KQL queries.
Legacy type-based selection of items in referenced project: This mode allows defining the scope of referenceable items via pre-defined item type and relation options. This mode has been superseded by the more powerful filter-based selection mode and should not be used in new project references.
Independent of the selected mode, a referencing project may also incorporate the release documents of a referenced project, which exposes those documents in the release and the Design History File. When including transitive documents, the documents of any referenced projects of the referenced project (etc.) are also exposed.
Note that cross-project references are directed, allowing references from the referencing project (A) to the referenced project (B). To also allow references in the other direction, a "reciprocal" relation from project B to project A needs to be added.
Software Item Specs in the referencing project may refer to a referenced project as a used service, which declares a dependency on the whole service without specifying which item within the referenced project is used exactly.
5.7.1.2. Filter-Based Selection
By default, when the filter-based selection mode has been enabled, all items of the referenced project will be part of the referenceable space, and no items will be part of the incorporated pool. The filters for referenceable and incorporated items can be defined as a simplified KQL statement (i.e. may filter items based on the item types, item relations and core field values only).
Additionally, a filter-based project reference may be configured to include items from projects that are transitively referenced by the referenced project (as defined by the references within the referenced project).
5.7.1.3. Legacy Type-Based Selection
This section is intended to document legacy behavior of existing projects. For new project references, or for complete cross-project traceability across non Test Case / Test Execution items, use the filter-based selection mode instead.
By default, when the type-based selection mode has been enabled, all items of the referenced project will be part of the referenceable space, including cross-project references to Anomalies and Risks; but it is also possible to define a more granular set of relation targets:
Requirements (as parent requirements or fulfilled requirements)
Software/Hardware Item Specs (as used items)
Tested items
Tests
When tests from another project are included as referenced items, they are treated as incorporated items, and show up on the All items, Test management, and Traceability pages of the referencing project. They can also be used to create Test Executions. By default, they are not included in the referencing project's release test plan, though.
5.7.2. Cross-Project Referenced Risks and Risk Controls
Given a project (A) that references another project (B), Ketryx will include any references and item details of risks and risk controls from project B in project A in the following areas, depending on the selected project reference mode:
Web pages
Risk management page
Filter-based selection mode: All the risks that are part of the incorporated pool are shown
Type-based selection mode: All the risks of the referencing project are shown
Risk controls page
Filter-based selection mode: All the items that are part of the incorporated pool and are considered a risk control based on the risk items found in the referenceable space are shown
Type-based selection mode: All the items that are considered a risk control based on the risk items found in the referenceable space are shown
Risk form
Filter-based selection mode: All the risks that are part of the incorporated pool are shown
Type-based selection mode: All the risks of the referencing project are shown
Documents: The information shown in web pages is also reflected in the corresponding evidence documents, including:
Risk matrix
Risk control matrix
Risk management file
Cyber risk management file
Ketryx includes risks and risk controls from project B in project A by principle of tracing, i.e. identifying relevant items to include by following a chain of risk control and 'introduces risk' relations that originate in project A (as defined by its configured referenceable space of items). Furthermore, any referenceable Test Cases (and resulting Test Executions) that test an item in this relations chain will be included in project A.
5.7.3. Version-specific Settings
For each version of the referencing project, a specific used version of each referenced project can be defined in the (referencing) version settings. This allows "locking in" a particular used version, and informs which record to show for each referenced item (which is particularly relevant if the title of the item changes over time). By default (if no specific used version is explicitly defined), the latest version of the referenced version will be used.
When showing cross-project references in release documents, the referenced project along with its used version (if explicitly defined) is shown as well.
5.7.4. Systems, Sub-systems, Services
Complex systems are usually structured in several layers, as follows (from higher to lower level):
a System consisting of one or more of the processes, hardware, software, facilities, and people, that provide a capability to satisfy a stated need or objective
Sub-systems, integrated collections of software items or hardware items organization to accomplish a specific function or set of functions
Services, self-contained and validated systems with specific predefined interface requirements
Typically,
higher-level ("parent") projects would incorporate the release documents of lower-level projects and reference used items in the lower-level ("child") projects (or reference a lower-level project "as a whole", i.e., as an opaque service), while
lower-level projects might reference requirements in the higher-level projects.
See the step-by-step guide about Setting up Cross-Project References for detailed instructions.
5.8. Differentiating Regulatory Regions
Ketryx supports building products for different regulatory regions, and similar cases where different variations of quality documents need to be produced. A "region" could be a geographic region such as EU vs. US, or a more abstract distinction such as Customer X vs. Customer Y.
At a higher level, different projects can be used for different regions, each having their own lifecycle and release documents. For instance, an EU-specific service could be maintained as its own project, with other projects referencing it as a used service as described above.
At a lower level, individual configuration items can be "labelled" with one or more regions, which makes them specific to those regions. Moreover, certain release documents can be configured to be region-specific. Region-specific release documents only contain items that are explicitly marked for their respective region, as well as region-independent items (not marked with any region).
The relevant advanced settings are Select text field options (to define the set of available regions in a project) and Region-specific documents. For other use cases, the field Regions can also be renamed, using the advanced setting Field names.
5.9 Audit change logs
Besides tracking changes of the actual work items, Ketryx is also capable of tracking changes to the Ketryx configuration itself to establish audit trails on the process administration level.
Audit change logs are captured either on the Ketryx organization or project level and include the following information:
Date and time of the change
Author of the change
Change type category
Change content to describe the details of the change (as JSON)
To view and download the Audit change logs for the current organization, navigate to Organization >> Audit change logs.
To view and download the Audit change logs for a project, navigate to [Project] >> History >> Audit change logs.
On each page, the data can be downloaded as a separate Excel file.
6. Step-by-step starter guide
6.1. Setting up an Organization
6.1.1. Step 1. Log into Ketryx
Log into the Ketryx platform (e.g., app.ketryx.com)
6.1.2. Step 2. Add members
6.1.3. Step 3. Create groups
6.1.4. Step 4. Assign members to groups
6.2. Setting up a Project
6.2.1. Step 1. Create a project with repositories
6.2.2. Step 2. Add a repository to an existing project
6.3. Connecting to Task/Issue Management Tool
6.3.1. Step 1. Log into Jira
Log into your Jira organization (e.g., your-company.atlassian.net)
6.3.2. Step 2. Get the Ketryx app
Add the Ketryx for Jira App.
6.3.3. Step 3. Connect a project to a specific Jira project
6.4. Setting up Cross-Project References for a System of Systems
This guide shows how to set up an interconnected System with a Sub-system and a Service used by it, and generating documents as described by section System of Systems.
6.4.1. Step 1. Create and connect projects
In the project settings for the System under References, add the Sub-system as a referenced project.
In the project settings for the Sub-system under References, add the Service as a referenced project.
When using the filter-based selection, set the Referencable items and Incorporated items filter to
none, then select References from ... as a used service, and Incorporate release documents ...When using the Legacy type-based selection, unselect all referenced items, then select References from ... as a used service, and Incorporate release documents ...
In the project settings for the Sub-system under References, also add the System as a referenced project.
When using the filter-based selection, set the Referencable items filter to RQ and Incorporated items filter to
none
6.4.2. Step 2. Create and connect items
6.4.3. Step 3. Create and associate versions
6.4.4. Step 4. Create release documents
6.5. Connecting to Cloud Provider
Further detail on connecting to a cloud provider (currently, Ketryx only supports AWS) can be found in MAN-04 Supply Chain Management: Cloud Dependencies.
6.6. Setting up Git-based configuration items
Please see MAN-09 Git-Based Configuration Items for step-by-step instructions on how to set up Git-based configuration items.
7. Records and Artifacts
Through Ketryx, teams can collect evidence and establish processes across their IT systems to meet regulatory requirements. Part of this regulatory requirement is to produce records and artifacts that proper design, development, distribution, deployment, and maintenance processes have been conducted.
This can include Quality Management System artifacts as well as Design Control artifacts and Change Control artifacts. The diagram below shows which artifacts can be created. The list below provides further detail about each artifact that can be automatically produced in Ketryx. Many other artifacts are possible to create, and the Ketryx team would be happy to support your journey of building. Please reach out for further information about artifacts.
7.1. SOUP dependencies
The Software Bill of Material Report covers software application dependencies both from open-source package managers and internally or manually entered information.
7.2. Traceability matrix
The Requirement Traceability Matrix shows that all tested requirements are traced to specifications and test cases.
7.3. Risk management file
Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report.
7.4. System requirements specification
The complete documentation describing the needs or expectations for a system or software, presented in an organized format and with sufficient information to understand the traceability of the information with respect to the other software documentation elements (e.g., risk management file software design specification, system and software architecture design charts, software testing as part of verification and validation).
7.5. Software Design Architecture Diagram
The software design architecture diagram displays Software Item Spec and Hardware Item Spec Configuration Items in a tree structure. Child-Parent relationships between Software Item Specs are defined by the Parent software items field and represented in the architecture diagram as solid arrows. Child-Parent "uses" relationships between Software Item Specs and between Software Item and Hardware Item Specs are defined by the Used items field and represented in the architecture diagram by a dotted arrow annotated with "uses". The color coding of the blocks in the architecture diagram is defined below.
7.6. System design specification
The complete documentation, including sufficient information that would allow the FDA to understand the technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness.
7.7. System design structure matrix
7.8. Unresolved anomalies
List of remaining software anomalies (e.g., bugs, defects) annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors, workarounds, and timeframe for correction.
7.9. Test plan
The test plan a validated system was tested against. The test plan must be approved before testing should start.
7.10. Testing report
Description of the testing activities at the unit, integration, and system levels. System level test case including expected results, observed results, pass/fail determination, and system level test report. unit and integration level test cases, including expected results, observed results, pass/fail determination, and unit and integration level test reports.
7.11. Cloud configuration report
The Software Bill of Material Report covers cloud dependencies and their exact configuration during V&V.
7.12. Code review report
Report with all the code comments.
Last updated
