Current Release Notes (v3.x)
Releases are grouped by the month they shipped, newest first.
November 2026 (v3.7.6 to v3.8.0)β
P4SaMD v3.8.0, 10 November 2026β
This release adds the Admin Console for installation operators, sign-in through your organization's own identity provider, a downloadable Traceability Matrix, and a smarter way of reading Git repositories during Brownfield import. It also fixes requirement link counters and AI evaluations on recent OpenAI models.
Admin Console
A separate console where installation operators manage organizations, users, memberships and licenses, with approvals for sensitive actions and a tamper-evident audit trail.
Sign in with your identity provider
Installations can let users sign in with their organization account. Invited users no longer receive an email or set a separate password.
Traceability Matrix download
Download the full requirement-to-evidence matrix as a CSV file from the Documentation Hub.
Upgrade notesβ
- Deploy backend and frontend together. The Traceability Matrix download and the single sign-on invite flow need both.
- Link counters on existing requirements may rise after the upgrade, because links made from the other side are now counted.
P4SaMD v3.7.6, 3 November 2026 (patch)β
A patch release that keeps the compliance checks used by Brownfield gap analysis exactly in line with the set shipped with each release. No new features and no changes to the user interface.
Upgrade notesβ
- This release only changes the policy engine. The backend and frontend stay at the versions shipped with v3.7.5.
- Existing gap-analysis findings stay attached to their compliance checks.
- If you run a gap analysis again against a framework rewritten in v3.7.5, you may see different findings than in a run made on v3.7.5.
October 2026 (v3.7.0 to v3.7.5)β
P4SaMD v3.7.5, 30 October 2026 (patch)β
A patch release that adds organization branding, two new Brownfield target frameworks, and a number of fixes, including a long-standing sign-in issue. It also updates the wording of many existing compliance checks to match the official regulation and guidance text more closely, which can change the outcome of a Brownfield gap analysis.
This release rewrites many compliance checks across IEC 62304, ISO 14971, IEC 62366-1, NIS2, MDCG 2019-16, the MDR, the AI Act, GDPR, and the FDA cybersecurity framework to match the official regulation and guidance text more closely, and turns off a number of NIS2 and GDPR checks that were not adding reliable value. If you run a gap analysis again against one of these frameworks, you may see different findings than before. MDR gap analysis sessions now also evaluate against the MDCG 2019-16 guidance, which can surface findings that did not exist in an earlier run.
This release adds the ability to store and generate tenant-authored document templates, and a published template will appear in the Documentation Hub next to the built-in documents. You can ask your System Administrator to create a customized template for you and publish it on your behalf. There is no page in the product yet for creating a template, so this is not something you can use on your own in this release.
Upgrade notesβ
- Deploy backend and frontend together for this release.
- If your organization relies on Brownfield gap-analysis results for NIS2, GDPR, the MDR, or MDCG 2019-16, review the note above before comparing a new run against an older one.
P4SaMD v3.7.2 to v3.7.4, 29 October 2026 (patches)β
Three maintenance releases that enable backend features to improve user experience and platform resilience. They bring no new features and no changes to the user interface.
Upgrade notesβ
- No action is required. The services shipped with v3.7.1 are unchanged; these releases only enable backend capabilities that were already in place.
P4SaMD v3.7.1, 20 October 2026 (patch)β
A patch release that fixes how SBOM scans classify a software item's dependencies, so that SBOM Reconciliation compares your System Design against the right components. No new features.
Upgrade notesβ
- This release only changes the SBOM scanning service. The backend and frontend stay at the versions shipped with v3.7.0.
- SBOMs scanned before this release keep their previous classification. Run a new SBOM scan on a software item to get the corrected direct dependencies and an accurate reconciliation.
P4SaMD v3.7.0, 19 October 2026β
Version 3.7 adds automatic acquisition of unit test reports from GitLab and GitHub Actions, a new Documentation Hub that gathers every exportable compliance artifact in one place, SOUP license and security-classification fields in System Design, and ten new US-oriented regulatory frameworks for Brownfield gap analysis.
Automatic Unit Test Report Acquisition
Configure a software item to pull its unit test reports automatically from a GitLab job or a GitHub Actions artifact, on a daily or weekly schedule, instead of uploading them by hand. A new Repository health view gives you one place to see every git-linked software item's acquisition status and trigger, pause, or re-enable it.
Documentation Hub
A single page to browse and export every compliance artifact your product has generated, grouped into seven sections, with a full, searchable history of who downloaded what and when.
Expanded Brownfield Regulatory Coverage
Ten new US-oriented frameworks are available for Brownfield gap analysis, covering FDA medical device reporting, premarket pathways, quality systems, unique device identification, and federal cybersecurity directives.
For developersβ
- The MCP tool catalog grows from 41 to 43 tools, adding update and delete operations for test cases.
- The Software Items list's tag filter now matches an item carrying any of the given tags rather than requiring all of them, and a new endpoint lists every tag used in a project.
- A test case's full execution history can be downloaded as a single file through a new export endpoint.
Upgrade notesβ
- Deploy backend and frontend together. Automatic acquisition, the reconciliation review for acquired reports, the test case detail page, the SOUP license and security-classification fields, tag-based filtering, and the Documentation Hub all depend on this release's backend; an older backend does not expose them.
September 2026 (v3.5.1 to v3.6.0)β
P4SaMD v3.6.0, 17 September 2026β
Version 3.6 adds a Reconciliation view that compares your System Design against the latest SBOM scan, component by component, and lets you resolve any mismatch directly from the platform. Unit test reports gain free-text tags and a two-step download (raw or traceability-enriched, as PDF, CSV, or JUnit XML). Git connection errors on a linked repository now explain what went wrong instead of showing a generic failure, and target market regions are limited to the platform's current assessed scope.
SBOM Reconciliation
A new Reconciliation view under System Design compares each software item's declared SOUP (Software of Unknown Provenance) components against its latest SBOM scan, and lets a reviewer resolve every mismatch: accept the scanned value, fill in a missing one, mark it approved as designed, match or unlink an item, create a draft entry, remove it from the design, or ignore it with a justification. A badge on the Software Items list flags any item with reconciliation outstanding.
Report Tagging and Two-Format Downloads
Unit test reports can now carry your own free-text tags, and the report list and test case list can be filtered by them. Downloading a report is now a two-step choice: Raw (the file as uploaded) or Traced (enriched with traceability information), each available as PDF, CSV, or JUnit XML.
Upgrade notesβ
- Deploy backend and frontend together. The reconciliation view, the specific Git failure messages, and the two-step report download all rely on responses this release's backend introduces; against an older backend they are unavailable or show a generic error, and a lapsed Git credential renders as a plain "not reachable" message instead of naming the credential as the cause.
P4SaMD v3.5.2, 11 September 2026 (patch)β
A frontend-only patch release with two interface fixes, in System Design and in Risk Management. No new features.
Upgrade notesβ
- This release only changes the frontend. The backend requirement stays at v0.10.1 or later, unchanged from v3.5.1.
P4SaMD v3.5.1, 9 September 2026 (patch)β
A patch release that completes the Verification safety alert feature 3.5.0 introduced: alerts are now raised automatically, instead of only being acknowledgeable. It also adds traceability coverage to each unit test report, lifts a limit that hid older test runs, and extends content-based file checking to project imports.
Automatic Safety Alerts
Verification now raises a safety alert on its own when a failed test result or a coverage gap affects a safety-relevant part of your system. Alerts are advisory and never block a report, its review, or its approval.
Coverage On Every Report
Each unit test report now shows how much of its own test population carries verification traceability, next to the gaps it already listed.
The safety alert list on a unit test report was always empty until now, because nothing raised alerts. After you upgrade, reports meeting the conditions below will show a safety alert banner. Alerts are advisory, they block nothing, and the upgrade changes no existing report data.
For developersβ
- The safety alert payload on a run summary has changed. It previously carried a severity and a message, and was always empty. It now identifies the triggering test case and software item, that item's safety class and risk control measure link, why and when the alert was raised, and its acknowledgement state. Any integration reading the old severity or message fields needs updating.
- A unit test report now carries its own traceability coverage counts and percentage, distinct from the project-level figure.
- A new endpoint validates an import file against the same rules the real upload applies, without a session and without storing anything. The type catalogs also report which extensions are refused outright.
Upgrade notesβ
- Deploy backend and frontend together. The safety alert payload is a shared contract between them. An older frontend against this release shows safety alert banners with no message and no severity, which means a safety warning that cannot be read.
- Some import file uploads that previously succeeded may now be refused, because files are checked against their actual content. This may affect an import routine that relied on a file whose extension did not match its contents.
August 2026 (v3.4.0 to v3.5.0)β
P4SaMD v3.5.0, 26 August 2026β
Version 3.5 realigns the risk matrix with ISO 14971:2019 terminology and closes the confirmed findings from a recent third-party penetration test. It also loosens System Design item typing, adds safety-alert acknowledgement to Verification, and fixes the most-reported cause of a stuck requirement quality score. This release requires regulatory/QA review before promotion in regulated environments, because it reclassifies existing risk records.
Risk Matrix Realignment
The risk level matrix now follows the ISO 14971:2019 "Option A" 5Γ5 matrix. Existing risks are recomputed automatically, and some severity/probability combinations that were previously Unacceptable are now Tolerable. This is a genuine reclassification, not a relabelling.
Security Hardening
Fixes for two confirmed findings from a penetration test targeting design-file rendering and upload: a stored script-execution issue in rendered design content, and insufficient validation of uploaded file content against its declared type.
This release renames the risk zone previously labelled ALARP to Tolerable, and replaces the risk matrix's severity/probability boundaries with the ISO 14971 "Option A" matrix. Every existing risk in your Risk Management File is automatically recomputed against the new matrix when you upgrade. Some risks that were previously classified Unacceptable are now classified Tolerable, including Severity 5/Probability 1, Severity 4/Probability 2, and Severity 3/Probability 3 combinations. This can change risk-control obligations for records that already exist, so have your regulatory/QA function review the change before promoting this release. Every reclassified risk gets its own history entry and audit log entry.
For developersβ
- The MCP tool catalog grows from 36 to 40 tools, adding SBOM download and unit test case management (
download_sbom,list_test_cases,get_test_case,create_test_case). - The risk-level query parameter and MCP schemas now validate against
Acceptable,Tolerable, andUnacceptableonly, returning400 invalid_query_parameterwith the allowed values for anything else.
Upgrade notesβ
- Deploy backend and frontend together. The
ALARPβTolerablerename is a shared contract between them; running mismatched versions can show blank or unmatched risk-zone labels. - Back up your database before upgrading. The risk matrix realignment rewrites existing risk records in place, and this step cannot be reversed. For a large Risk Management File, expect the upgrade to take longer than usual: it writes a history and audit entry for every reclassified risk.
P4SaMD v3.4.0, 6 August 2026β
Version 3.4 introduces native Software Bill of Materials (SBOM) generation and a new approval workflow for uploaded unit test reports, alongside smaller improvements to the Requirements and System Overview pages.
Native SBOM Generation
P4SaMD now generates a CycloneDX Software Bill of Materials directly, with no separate scanning tool or CI/CD integration required. Trigger a scan manually, automatically on a repository/version change, or on a daily/weekly schedule, then browse components, compare versions, and export.
Run Approval & Guided Traceability Review
Uploaded unit test reports now go through an approval lifecycle: Incomplete β Traceability Required β Ready for Approval β Pending Third-Party Approval β Approved. A submit-for-approval flow sends a report to a designated reviewer, and an opt-in guided review walks you through linking test results to software items first.
For developersβ
- Fixed an MCP defect where creating a software item or SOUP entity via the MCP tool catalog always failed, and corrected an error message that referenced the wrong domain for software-item hierarchy violations.
- Requirementβrequirement traceability MCP tools now propagate a real request ID on error responses, for easier correlation when debugging.
- Evaluation stall detection (introduced in v3.3.0) now allows a longer window before failing a stalled job, reducing false positives on legitimately slow evaluations.
July 2026 (v3.3.0 to v3.3.1)β
P4SaMD v3.3.0, 9 July 2026β
Version 3.3 focuses on administrative visibility and evaluation reliability: organization admins get a clearer view of tenant status and plan usage, Product Information now keeps a change history, and both Brownfield and AI-assisted evaluations recover more gracefully from interruptions.
This release fixes a defect in the Brownfield compliance check where certain gaps could be reported as compliant when they were not. If you rely on a Brownfield evaluation completed before 9 July 2026, re-run the evaluation (using the new Retry Evaluation button, or by starting a new session) to get corrected results.
For developersβ
The requirements REST API and MCP tool catalog gained new capabilities for managing requirement hierarchy programmatically: re-parenting a requirement, setting labels and an initial status at creation, endpoints for managing sections, and creating requirement-to-requirement traceability links. These are currently available via the API and MCP only; UI support is planned for a future release.
P4SaMD v3.3.1, 9 July 2026 (patch)β
A same-day patch fixing a display defect: requirement level labels could show the wrong text in the requirements table. No other user-facing changes.
June 2026 (v3.1.0 to v3.2.0)β
Three releases shipped in June: the Whisper AI Assistant and AI configuration (v3.2.0), a storage migration (v3.1.1), and the System Design lifecycle and team-administration work (v3.1.0).
P4SaMD v3.2.0, 30 June 2026β
Version 3.2 introduces Whisper, the in-platform AI assistant, together with the tenant-level AI configuration that powers it. This is the first release of the AI advisor capability previously on the roadmap.
Whisper AI Assistant
A new AI assistant available on every project page, opened from the sparkles icon in the top bar. Whisper surfaces compliance suggestions for the active version and offers an interactive chat that can read your project and propose changes for you to confirm.
Compliance Suggestions
Whisper analyzes your active version and lists AI-detected compliance findings, sorted by priority, each with a normative reference, reasoning, remediation steps, and a confidence indicator. You can run a fresh analysis on demand and dismiss, resolve, or reopen each finding.
Conversational Chat with Confirmable Actions
Ask Whisper questions in natural language and get streamed answers. When the assistant proposes a change to your data (for example creating a requirement), it presents a Confirm / Decline card. Nothing is changed without your explicit approval, and every confirmed or declined action is recorded in the audit log.
AI Configuration & LLM Profiles
Administrators can enable AI features per organization and assign an LLM provider and model to each workload (Chat and Evaluation) from a new LLM Profiles settings page, with live credential validation. Providers can expose an allow-list of selectable chat models, and the live model list can be discovered directly from the provider.
The Whisper AI Assistant ships in beta in v3.2.0 and is available on request. It is not enabled by default. Contact Mia-Care to have it enabled for your organization. Coverage and proactive guidance will expand in upcoming releases.
For developersβ
- The MCP tool catalog grew to 17 tools, adding risk-management and software-item domain tools, now shared as a single source of truth with the Whisper agent.
- AI assistant activity (confirmed/declined actions and conversation creation) is now written to the audit log.
P4SaMD v3.1.1, 12 June 2026β
A maintenance release that migrated file storage to a managed object store.
Files uploaded before this release are not accessible afterward. No data was migrated between the old storage and the new GCS bucket, so any previously uploaded files must be re-uploaded, including design files in the System Design section. This was an accepted trade-off given the platform's current internal-only audience and the small volume of stored data.
P4SaMD v3.1.0, 11 June 2026β
Version 3.1 deepens the native SDLC artifact management introduced in v3.0, with a focus on the System Design workspace, formal lifecycle controls, and team administration.
For developers: extended MCP coverageβ
The bundled MCP server gained broad new read/write coverage (requirement lifecycle transitions, full risk register management, traceability links, software item browsing, version management, and design-file access), so external AI assistants and coding agents can operate on project data without REST access.
May 2026 (v3.0.x)β
The v3 product line launched in May with v3.0.0, followed by a series of v3.0.x patch updates.
P4SaMD v3.0.0, 26 May 2026β
Version 3.0 is a complete re-architecture of P4SaMD and the beginning of the v3 product line. The platform is standalone and operates independently of any third-party software infrastructure.
What's Newβ
Standalone Platform
P4SaMD v3 runs as an independent product with its own user interface. It no longer requires Mia-Platform Console or any other external platform to be deployed or in use by your organization.
Federated Authentication
Authentication in v3 uses a federated OIDC identity provider bundled with the P4SaMD installation. The two-token authentication model (login token plus tenant-scoped token) keeps session management IdP-independent. Switching to a different identity provider in the future requires only a configuration update.
Multi-Tenant Architecture
A single P4SaMD installation now serves multiple independent organizations simultaneously. Each organization has complete data isolation from others on the same installation. Users can belong to multiple organizations and switch between them without logging out.
Native Work-Item Management
Requirements, risks, tests, and change requests are now managed natively inside P4SaMD. An external ALM tool (such as Jira) is no longer required to start using the platform. External ALM integrations remain available as optional bidirectional synchronization features.
Multiple Projects per Organization
Organizations can now manage multiple medical device software projects in a single P4SaMD instance. Each project has its own team, configuration, compliance context, and version history.
Self-Service Configuration
Organizations and projects can be configured autonomously through the platform interface, without asking Mia-Care to make changes on your behalf. This includes integration setup, workflow configuration, and organizational settings.
Brownfield Import
Use the Brownfield Import wizard to onboard existing software projects. A six-step guided workflow collects project context, technical assets, and existing documentation, then triggers an automated compliance gap analysis and generates a prioritized remediation plan.
Requirements Management (v3 Architecture)
Requirements are now managed as native platform entities with a hierarchical tree structure, lifecycle statuses (Draft β In Review β Approved β Verified), bidirectional traceability, and import/export capabilities. No external ALM synchronization is required.
Version Management
Workspace versions provide IEC 62304-aligned configuration management. Draft versions support active development; released versions are permanently locked as compliance records.
Upgrading from v2β
P4SaMD v3 is a new platform. There is no direct in-place migration path from v2. To move from v2, we recommend using the Brownfield Import feature to onboard your existing projects into the v3 platform. Contact Mia-Care for migration support.
Patch updates: late May 2026 (v3.0.x)β
For features planned for upcoming releases, see the Product Roadmap.