Medical device software with audit‑ready design controls

Yes, as software used in your quality management system, and in proportion to the risk of each use. ISO 13485 asks for validation of such software before first use and after changes. We list the intended uses, assess the risk of each one, and prepare the configuration specification and test scripts for the uses that matter, such as electronic signatures, audit trails and trace reports. Your quality team approves the validation, and we keep it current with each upgrade.

Through ReqIF, agreed per partner. We set up an exchange definition for each supplier: which modules and attributes go out, which come back and who may edit them. Their answers are imported next to the previous delivery, so you see what changed before you accept it. SOUP and purchased components get their own requirements and version records, linked to the risk analysis, so a supplier change shows which risk controls to check again.

With configurations instead of copies. Common requirements, risk controls and tests are kept once, and each model or market is a configuration that adds its own items. IBM Engineering Lifecycle Management Global Configuration Management records which version of each item a release uses, so the design history file for any model can be generated from its own baseline. A change to a common item shows every model it affects, with one impact analysis instead of several.

Product by product, not all at once. Released products often stay on IBM Engineering Requirements Management DOORS (9.x) until their next design change, while new products start in IBM Engineering Requirements Management DOORS Next. When a product moves, modules, attributes and links move with their original IDs, and released baselines are kept, so earlier submissions stay reproducible. The migration is treated as a validated change, with a record of what moved. DXL scripts are inventoried first and most are replaced by configuration or views.

Yes. Design inputs, risk controls and verification stay in IBM Engineering Lifecycle Management, where your design history needs them. Development work stays in Atlassian Jira and code in GitLab. We link work items and merge requests to the software requirements they implement, through OSLC-based integrations or a synchronization we configure for your process. The trace from risk control to code is then complete, and the integration itself is covered in your software validation.

In the same project, with separate artifact types and link rules. Threats, security risks and security requirements link to the same device functions, software requirements and tests as hazards and risk controls. Where a security risk can lead to harm, the link to the hazard is explicit. One change then triggers both safety and security impact analysis, and the software bill of materials and security test evidence come from the same baseline as the rest of the submission.