How to generate the Design History File for your medical device
Overview
In this How-to Guide, we lay out the steps for creating the design documentation in Ketryx required for a medical device. This includes covering the needed Configuration Items (CIs) to create each document in the Ketryx default release documents. By completing the steps in this guide, you will create all the needed information to generate your technical documents and design history file, which are required, for example, by the FDA, for pre-market and other regulatory submissions, as well as full “V-model” traceability from requirements to verification (see MAN-01 Ketryx Lifecycle Management).
The Guest role provides read-only access to your Ketryx organization. Users with the Guest role (hereafter, guest) can view content within the organization and its permitted projects, but cannot make any changes or modifications. This role is ideal for staff who need context without editing capabilities, external auditors requiring system access, or stakeholders who need visibility into your quality management system.
How to Use This Guide
This guide is broken out into a number of sections that map Ketryx Configuration Items to the contents of key Release Documents. In addition to step-by-step information about populating key information in each type of Configuration Item, the final section of this guide provides an overview of additional default Release Documents and the key types of Configuration Items that they contain.
While many of these Configuration Item types can be created in parallel, by following this guide in the recommended order and by diligently populating item metadata and traceability, you will build a comprehensive Design History File (DHF) required for FDA pre-market submissions and other regulatory approvals.
This structured approach not only streamlines the generation of essential technical documents like the SRS, SDS, Risk Management File, and Test Reports, but also helps ensure compliance with regulatory requirements from bodies such as FDA. The continuous use of the Traceability Matrix and incremental versioning practices will further support your organization’s ability to maintain a controlled, traceable, and auditable record throughout the entire medical device lifecycle.
Tracking Progress
Continuous Verification with the Traceability Matrix
It is recommended that you review the Traceability Matrix (see MAN-07 Traceability) and use it as a guide early and often throughout the full lifecycle of Configuration Items being managed in Ketryx. It will help you visualize the relationships required by 21 CFR 820 and ISO 13485 for design controls and also see if anything is missing and what to fix. This is also why it is a required artifact in many regulatory regions.
Release Progress Check
The release screen also provides a consolidated view of your readiness, showing which design control activities are complete and which documents are generated (see MAN-02 Software Release Process). Use it as a quick dashboard to identify gaps in your DHF.
Leveraging AI with Ketryx Assistant
The Ketryx Assistant can accelerate a variety of tasks and document creation throughout this process. Examples of how to use it effectively include:
Requirements & Specification Generation: “Draft user requirements for [my device] that [have these key functions]”
Risk Analysis: “Review all requirements and specifications in this project and draft potential risks”
Test Case Creation: “Suggest test cases for requirements RQ-001 through RQ-010”
Traceability Review: “Check traceability gaps between requirements and test cases”
Prerequisites
Before starting, ensure you have:
Understanding of your device’s intended use and user needs
Team members assigned with appropriate roles (optional)
1. Requirements
Key resulting document: System/Software Requirement Specification
Document description: Provides a written definition of the software functions, which is essential for validation and regulatory submissions.
Start with:
Create Use Case Requirements - see WI-01 Requirement
Configuration Item Type: Requirement (with Requirement Type = "Use case")
Purpose: Captures user needs and high-level functional goals.
Ketryx Traceability page: Use Cases
Then:
Create Design Inputs: System/Software Requirements - also WI-01 Requirement
Configuration Item Type: Requirement (all other types except "Use case")
Purpose: These are actionable, detailed requirements derived from use cases that explain how a software system can perform the use cases
Traceability: Relate to one or more applicable Parent Requirements of Type “Use case”
Ketryx Traceability page: Design Inputs
Metadata:
All Requirements: Populate Requirement Type and Context
Design Inputs / System-type Requirements: Populate Context where applicable (for example cyber or safety)
Why:
Requirements are the foundation for all design, risk, and test activities. They drive traceability and are central to SRS and traceability matrix documents
Context is used to flag items that should be considered for any associated Risks
2. Design Specifications & Risk-related Items
Creation of Design Specifications and Risk items will often be performed by different people within an organization and can often be done in parallel.
Key resulting document: Software Design Specification / Software Detailed Design
Document description: Describes the technical implementation of software functions, outlining how the software design fulfills the requirements of the Software Requirements Specification (SRS) and detailing software units, interfaces, and data flow
Software & Hardware Item Specs:
Create Software Item Specs and Hardware Item Specs (if applicable) - see WI-02 Software Item Spec
Configuration Item Types: Software Item Spec and Hardware Item Spec
Metadata:
Traceability: Relate to one or more applicable Parent Requirements
Traceability: Relate to other applicable SW items to start building the architecture of the device
Context: Populated where applicable to flag items to be considered for any associated Risks
Why:
Design specs show how requirements are implemented and are needed for the SDS and architecture documents
Note about Configuration Item Type: Tasks - see WI-03 Task
Tasks are a way to assign team members to perform work. They can provide all the context needed to users to perform the work (e.g. the RQ or SW item to be implemented) and help track that the work is done.
While Tasks are not the primary Configuration Item Type included in any Release Documents, Tasks that Trace back to Requirements, Software Item Specs, CAPAs, and other Configuration Items will appear in Release Documents
A common reason to use the Task configuration item in Ketryx is to provide developers with additional information on how to perform an implementation that will not show up in regulatory submissions, and track that it was indeed implemented
Key resulting document: Risk Management File
Document description: A comprehensive collection of records documenting all risk management activities undertaken throughout the entire lifecycle of a medical device
Risk Analysis & Management Items:
Create Risks, Risk Analyses, and define Risk Controls - see MAN-08 Risk Management and WI-10 Risk
Configuration Item Types: Risk, Requirement, Software Item Spec, Hardware Item Spec
Metadata:
Traceability: Relate to applicable Requirements where the risk is introduced. Requirements with context Safety, as marked in the above steps, are a good checkpoint to review establish this traceability
Traceability: Relate to Requirements and Software Item Specs that Control each Risk
For Requirement, Software Item Spec, Hardware Item Spec
Context: Only items with Context = Safety are included in the “Identification of characteristics related to safety” section
Why:
Early risk management is required by ISO 14971 and FDA. Risks and controls must be traceable to requirements and design
3. Version
Key resulting document: The Version configuration item is the central organizing entity for all Release documentation
Particularly during the development process, it can be useful to iterate often:
Control all of your Configuration Items created so far
Create a Release as a “snapshot”, for example, v0.0.1
Generate Release Documents of interest, e.g., SRS and SDS
Repeat for successive iterations
Create:
Configuration Item Type: Version - see MAN-02 Software Release Process
Why:
All default Release Reports are generated for a specific version of the product
When ramping up with Ketryx at your company, in a new area of your company, or etc., it is good practice to regularly review and Approve Configuration Items, per your QMS, rather than creating all Configuration Items and then having to later review and Approve large numbers of items at once. For example, the following can be an effective way for your organization to incrementally adopt Ketryx.
Create the first round of Requirements, Software Item Specs, Risks, etc.; create Release Version v0.0.1
Work through the process of Releasing v.0.0.1 as a non-production version, which will require you to exercise your release process including: Approving each Configuration Item, conducting Risk Management, confirming proper traceability is established, and generating Release Documents
As additional Configuration Items are created - creating more Items as described in the above sections as well as additional Types of Items per the following sections of this guide - repeat the above to generate successive non-production snapshot Releases
4. Test Cases, Test Plan, Test Executions
Key resulting documents: Test Plan and Testing Report
Document description: A Test Plan outlines the strategy, scope, objectives, and methodology for software testing, while a Testing Report documents the results, detected defects, and overall outcome of the executed tests
See MAN-06 Test Management for additional information.
After creation of Design Specifications and Risk-related items:
Create Test Cases
Configuration Item Type: Test Case - see WI-04 Test Case
Metadata:
Traceability: Relate to one or more applicable Requirements and Software / Hardware Design Specs
Why:
Test Cases demonstrate that Requirements and Risk Controls are verified, supporting the Testing Report and Traceability Matrix
After creation of Test Cases:
Decide which Test Cases are included and excluded for the given Release Version
Configuration Item Type: Test Plan
Metadata:
Populate the Rationale for exclusion for any excluded Test Cases
Why:
The Test Plan specifies which Test Cases are required for a particular release. It serves a number of purposes, including traceability and compliance as well as forming part of the documentation required for audits and regulatory submissions.
After creation of Test Cases:
Create Test Executions
Configuration Item Type: Test Executions - see WI-05 Test Execution
Metadata
Traceability: Relate to applicable Test Cases
Why:
Test Executions provide objective evidence for verification and validation for a particular Release, which is required for FDA submissions and other purposes
5. Dependencies
Key resulting documents: SBoM - SOUP - Software Configuration Report
Document description: An SBoM - SOUP - Software Configuration Report identifies and details all software components, including commercial, open-source, and Software of Unknown Pedigree (SOUP), their dependencies, and configuration settings within the medical device
See MAN-03 for additional information.
Create:
Connect GitHub repository to Ketryx or submit dependencies via a supported format, such as CycloneDX - see, e.g., MAN-03 and Working with CycloneDX
Metadata
Traceability: Relate to applicable Configuration Items, such as Software Item Specs; available metadata fields are described in MAN-03
Why:
Dependencies in Ketryx are used to manage and track all third-party and internal software components (including open-source and SOUP—Software of Unknown Provenance) that your system relies on
6. Vulnerabilities and Vulnerability Impact Assessments
Key resulting document: Vulnerability Report
Document description: Documents identification, assessment, and summary of known security vulnerabilities in device software, including their potential impact and mitigation status
Context:
Note that a Vulnerability is not a standard Ketryx Configuration Item type in the same way as Requirements, Risks, or Software Items, but it is managed as a first-class record within the Ketryx platform
It is highly recommended to enable the Enable vulnerabilities as configuration items setting in your project's Advanced settings. This ensures that vulnerability impact assessments are treated as full configuration items, requiring them to be controlled before a release, which is critical for regulated environments. See WI-12 Variants and Versions
Creation:
When a Ketryx Project contains dependencies, Ketryx automatically detects vulnerabilities and presents them on the Vulnerabilities page within the SBOM module - see Vulnerability Management
Alternatively, vulnerabilities from a scanning tool that you already use can be reported via CycloneDX
Vulnerabilities are not available in the standard "Create item" dropdown on the All Items page, and cannot be edited in the same way as other configuration items (like Requirements or Risks)
Impact assessments should be created for each vulnerability that shows up on the vulnerability page
Metadata
Traceability: Relate to applicable Configuration Items, such as Risks and mitigations such as Software Item Specs; available metadata fields are described in MAN-03 - Vulnerability Management
Why
Each Vulnerability is linked to the affected dependencies and can be connected to Requirements, Software Item Specs, Risks, and Test Cases, enabling you to align cybersecurity risk management with your overall product development and compliance processes
7. Change Requests and CAPAs
Key resulting documents: Change Request Verification Report and Change Management File - note that these reports are not default Release Documents
Document description: A Change Management File systematically documents all changes to a medical device software throughout its lifecycle. A Change Request Verification Report confirms that implemented changes have been successfully verified and validated to meet their intended requirements
Create:
Configuration Item Type: Change Request/CAPA
Metadata:
Traceability: Relate to affected items, such as Anomalies and Software Item Specs - see WI-08 Change Request and WI-09 CAPA
Why:
Change Requests and CAPAs in Ketryx ensure that all changes and corrective actions are managed in a controlled, traceable, and compliant manner, supporting both product quality and regulatory requirements
8. Anomalies and Complaints
Key resulting document: Problem Report
Document description: Documents identified software issues or defects, detailing their impact, severity, and resolution, and is used to track the problem's lifecycle
Create:
Configuration Item Type: Anomaly - see WI-06 Anomaly
Metadata
Traceability: Relate to applicable items such as CAPAs, Change Requests, and other Items
Why:
The Problem Report in Ketryx is a document that provides a comprehensive overview of anomalies (problems, bugs, defects) associated with a particular software version
It typically includes both new unresolved anomalies and resolved anomalies relevant to the release
9. Document
Key Release Documents that can contain references to Document Configuration Item Types: Release Notes, Traceability Matrix, System Requirements Specification / System Design Specification
Create:
Configuration Item Type: Documents - see WI-11 Document and Document Templating
10. Additional Ketryx default Release Documents
The Configuration Items described above also populate into a number of additional Ketryx default Release Documents. We describe these documents in this section and list key Configuration Item types that populate each.
Traceability Matrix
Document description: Regulatory standards, such as FDA requirements, ISO 13485, and IEC 62304, require clear evidence that requirements are fulfilled and verified. The Traceability Matrix provides this evidence in a structured, reviewable format - see MAN-07 Traceability
Release Notes
Document description: Summary of the changes, enhancements, and fixes introduced in a new version of device software, providing clear information for users and regulators about updates relevant to safety and effectiveness
System Architecture Chart
Document description: Diagrammatic representation that illustrates the major software components, their relationships, and interactions within the device system to support understanding of the software’s structure and data flow - see MAN-01 Ketryx Life Cycle Management
Training Status Report
Document description: Overview of the training status and compliance of users within a project, showing which team members have completed required training on controlled documents
Context:
The Training Status Report primarily contains information about Users and their acknowledgement of having trained on training-related Documents
Note that Users are not a standard Ketryx Configuration Item type in the same way as Requirements, Risks, or Software Items, but it is managed as a first-class record within the Ketryx platform
Provides a summary of the training status of all project members, documenting which users have acknowledged and completed training on required documents to ensure compliance with organizational and regulatory requirements - see WI-11 Document
Last updated
Was this helpful?