2.4.2. Planned Artifacts
This section lists the planned certification artifacts and resources that will be made available to support customer certification efforts.
This list reflects Proximie’s current planning as of 14 May 2026 and is subject to change based on evolving regulatory requirements, customer needs, and internal development progress. Proximie is committed to providing comprehensive certification support and will update this list as new artifacts are developed and released.
2.4.2.1. Quality & Process Management
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Quality Management System Reference |
Establishes that PxSDK development operates under a QMS (referencing ISO 13485 or equivalent). Defines the scope of QMS coverage, roles relevant to software development, and cross-references the Software Development Plan. Required context for all other lifecycle documents. |
IEC 62304 §4.1 |
Software Development Plan |
Master plan defining the software development lifecycle model, deliverables, activities, tools, and standards for PxSDK. Central document that references all subordinate plans and defines how the development process is executed. |
IEC 62304 §5.1 |
Software Configuration Management Plan |
Defines how software configuration items (code, documentation, tools, SOUP) are identified, version-controlled, change-controlled, and baselined. Ensures reproducibility and traceability of all releases. |
IEC 62304 §8 |
Build Environment Specification |
Specifies the controlled build and integration-test environment used to produce PxSDK release artifacts. Documents OS, toolchain versions, security update policy, access controls, and reproducibility requirements. |
IEC 62304 §5.1 |
2.4.2.2. Software Requirements & Architecture
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Software Requirements Specification (SRS) |
Complete, unambiguously identified list of functional and non-functional requirements for PxSDK, including safety and SOUP requirements. Each requirement is uniquely identified, verifiable, and traceable to tests. |
IEC 62304 §5.2 |
Software Architecture Document |
High-level design showing decomposition of PxSDK into software items (PxCore, PxMedia, PxUtility, PxRestApi), their interfaces, data flows, and SOUP integration points. Identifies safety-relevant components and their segregation. |
IEC 62304 §5.3 |
2.4.2.3. Safety Classification & Risk Management
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Software Safety Classification |
Formal determination of PxSDK’s IEC 62304 safety class (A, B, or C), with documented rationale based on the SDK’s intended use and contribution to hazardous situations. |
IEC 62304 §4.3 |
Software Risk Management Plan |
Defines the risk management activities specific to software, including hazard identification methods, risk estimation criteria, risk acceptance criteria, and verification of controls. Integrates with overall product risk management. |
IEC 62304 §7, ISO 14971 |
Software Hazard Analysis |
Systematic identification of hazards that PxSDK could cause or contribute to, using FMEA or similar method. Analyses failure modes of each software item and SOUP component, with potential consequences documented. |
IEC 62304 §7.1 |
Software Risk Analysis |
Estimates risk (severity × probability) for each identified hazard and determines which risks require control measures based on defined acceptance criteria. |
IEC 62304 §7.1, ISO 14971 |
Software Risk Control Matrix |
Documents risk control measures for each unacceptable risk, verification of control effectiveness, and resulting residual risk. Provides full traceability from hazard to control to verification. |
IEC 62304 §7.2, ISO 14971 |
Software Safety Requirements |
Requirements derived from risk control measures that must be implemented in software. Each requirement carries a unique “SR-” identifier and is traceable to its originating risk control and to test cases. |
IEC 62304 §7.2.2 |
Residual Risk Summary |
Documents residual risks that remain after PxSDK risk controls are applied. Written for OEM integrators, describing residual risks in actionable terms, assumptions for safe use, and integrator responsibilities. |
IEC 62304 §7.3 |
2.4.2.4. Testing & Verification
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Software Unit Verification Plan |
Defines the strategy for unit testing, including scope, methods, tools (Google Test/Google Mock), code coverage targets, and pass/fail criteria. |
IEC 62304 §5.5 |
Software Integration Plan |
Defines how software items are integrated together and with SOUP components, including integration sequence, strategy, environment requirements, and success criteria. |
IEC 62304 §5.6 |
Software Integration Test Specification |
Test cases for verifying correct integration between software items and with SOUP components. Each test case has a unique ID, preconditions, steps, expected results, and traceability to the architecture document. |
IEC 62304 §5.6 |
Software System Test Plan |
Defines the approach for system-level testing including functional, performance, stress, and security tests. Verifies that the complete software system meets requirements. |
IEC 62304 §5.7 |
Software System Test Specification |
Test cases for system-level verification of PxSDK against software requirements. Each test case traces to one or more requirements and provides evidence of requirement verification. |
IEC 62304 §5.7 |
Software System Test Report |
Per-release record of test execution, pass/fail status, defects found, and overall requirements coverage. Provides evidence that system tests were completed prior to release. |
IEC 62304 §5.7 |
Requirements Traceability Matrix (RTM) |
Bidirectional traceability from system requirements through software requirements, design, implementation, and test cases. Demonstrates complete requirements coverage and supports change impact analysis. |
IEC 62304 §5.1.1 |
Validation Plan |
Defines how PxSDK is validated for its intended use, including validation scope, methods, OEM integration scenarios, and the boundary between Proximie’s validation responsibilities and those of the OEM integrator. |
IEC 62304 |
2.4.2.5. Security
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Threat Model |
Systematic analysis of PxSDK’s attack surface using STRIDE (or equivalent), covering data flows, trust boundaries, threat actors, attack vectors, and mitigations mapped to threats. |
FDA Cybersecurity Guidance, IEC 62443 |
Cybersecurity Risk Assessment |
Security-specific risk analysis identifying assets, threats, vulnerabilities, and security controls for PxSDK. Incorporates SOUP security risks and aligns with FDA premarket cybersecurity guidance. Complements the safety risk analysis. |
FDA Cybersecurity Guidance, MDR |
Public Security Scan Report |
Summary of ECR security scan results for both standard and hardened PxSDK Docker images (Ubuntu 22.04 and 24.04, plain and Ubuntu Pro hardened variants), published in public documentation. |
— |
2.4.2.6. SOUP (Software of Unknown Provenance / Third-Party Components)
Artifact |
Description |
Regulatory Reference |
|---|---|---|
SOUP List |
Enumeration of all third-party software components integrated into PxSDK. Documents name, version, supplier, safety classification, intended use, and qualification approach for each component. Auto-generated as part of the CI/CD pipeline. |
IEC 62304 §8.1.2 |
SOUP Qualification Rationale |
Independent qualification evidence for SOUP components not covered by Ubuntu Pro ESM (e.g. Boost, Microsoft GSL, WebRTC Audio Processing). Documents supplier assessment, security audit history, CVE analysis, and functional verification for each component. |
IEC 62304 §8 |
SOUP Anomaly Register |
Living log of known anomalies (CVEs, bugs, security advisories) in SOUP components, with applicability assessment for each anomaly and disposition decision (N/A, Accepted, Mitigated, Remediated, or Monitoring). |
IEC 62304 §8 |
SOUP Monitoring Procedure |
Defines how SOUP components are monitored for security vulnerabilities and anomalies after release. Covers monitoring sources, triage process, response SLAs by severity, re-qualification triggers, and CI/CD integration. |
IEC 62304 §6.1 |
Open Source License Compliance Matrix |
Documents all open source licenses applicable to PxSDK SOUP components (with SPDX identifiers), compliance obligations, Proximie’s compliance status, and NOTICES file content for distribution to OEM integrators. |
Legal / IEC 62304 |
2.4.2.7. Maintenance & Problem Management
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Software Maintenance Plan |
Defines how released PxSDK versions are maintained, including bug fixes, security patches, and updates. Covers the feedback collection process, impact analysis, modification process, and customer notification. |
IEC 62304 §6 |
Software Problem Resolution Procedure |
Defines how software problems (defects, anomalies, customer issues) are reported, categorised, investigated, and resolved. Includes safety impact assessment requirements and criteria for issuing advisory notices. |
IEC 62304 §9 |
Problem Report Template |
Standardised format for logging software problems, including problem ID, affected version, description, severity classification, safety impact assessment, root cause, and resolution/verification fields. |
IEC 62304 §9 |
2.4.2.8. Release Management
Artifact |
Description |
Regulatory Reference |
|---|---|---|
Software Release Package Definition |
Defines the contents and structure of each PxSDK release, including binaries, headers, libraries, API documentation, SBOM, NOTICES file, and release notes. Documents version numbering scheme and release verification checklist. |
IEC 62304 §5.8 |
Release Notes |
Per-release notes documenting new features, bug fixes (with issue IDs), known issues, SOUP/dependency changes, breaking changes, and security fixes. Provided with each SDK release. |
— |