Frequently Asked Questions

PMX OS serves six primary stakeholders simultaneously through tailored, role-specific interfaces sharing a unified graph backplane. Hardware and embedded firmware engineers use the platform directly within their Git pull requests, CAD check-ins, and CLI tools to see downstream safety impacts before committing. Regulatory Affairs specialists utilize the platform to automate predicate substantial equivalence mapping, evaluate 510(k) vs. Letter-to-File decision trees, and synchronize multi-country submissions. Quality assurance managers rely on the continuous trace matrix to eliminate manual Excel audits and isolate CAPA blast radii in minutes. Data science teams leverage the PCCP module to govern machine learning model retraining and dataset provenance, while enterprise leaders maintain real-time portfolio visibility across global manufacturing sites and notified bodies.

No. PMX OS is designed explicitly as a non-destructive intelligence overlay that sits directly atop your existing systems of record. It does not require rip-and-replace migrations of your PTC Windchill, Siemens Teamcenter, MasterControl, Veeva Vault, Atlassian Jira, or SAP S/4HANA instances. Instead, PMX OS deploys federated semantic connectors that extract entities, metadata, revision baselines, and test records via secure APIs and webhooks. These extracted nodes are synthesized into a centralized knowledge graph that provides bidirectional traceability and impact simulation without altering your underlying database schemas. Your engineers continue using Git and CAD, quality continues approving documents in their eQMS, and procurement manages inventory in ERP, while PMX OS orchestrates cross-functional intelligence across them.

The PMX Knowledge Graph Engine models medical devices as directed acyclic hypergraphs composed of strongly typed ontological entities. Core entity types include Physical Components (electrical BOMs, sensors, mechanical housings), Functional Requirements (user needs, system specs, software design descriptions), Clinical Risks (hazards, failure modes, hazardous situations per ISO 14971), Verification Protocols (bench test procedures, automated test scripts, clinical datasets), and Regulatory Artifacts (510k sections, GSPR checklists, CE certificates). Edges between these nodes represent semantic relationships such as implements, mitigates, verifies, satisfies, and regulates. By enforcing bidirectional graph traversal rules, the engine tracks multi-hop causality, ensuring that a physical sensor change immediately highlights invalid verification evidence and regulatory exposure.

The Change Simulator is a deterministic impact analysis engine that executes recursive dependency graph traversals whenever a modification is proposed. When an engineer or procurement specialist specifies an alternate part—such as substituting temperature transducer S-18 with S-22—the simulator traces all outgoing and incoming relational edges from that component node. It evaluates electrical tolerances, physical thermal boundaries (such as IEC 60601-1-11 surface temperatures), affected software drivers, and linked risk mitigations. The resulting "blast radius" identifies all downstream nodes whose verification status has been invalidated, flags temporary evidence gaps, and determines whether the modification alters substantial equivalence against cleared predicate devices, outputting an actionable delta report before any physical tooling commitments are made.

CardioSense Pro v3.8.2 serves as a complete reference implementation within PMX OS, exemplifying how multi-site development teams coordinate complex electro-mechanical devices. The platform maintains version-controlled graph baselines representing the cleared commercial configuration. When an engineering change request such as CHG-1024 is initiated to replace sensor S-18 due to supplier lead-time constraints, PMX OS branches the device graph into an active simulation workspace. Engineers across different sites (e.g., Minneapolis hardware, Galway firmware, and Singapore manufacturing) test alternative routing, verify thermal requirement REQ-0184, and re-run bench verification protocol V-0183 in an isolated sandbox. Once all verification evidence is cryptographically signed, the change is merged into the master baseline, ensuring synchronized global configuration control.

Under FDA guidance, a pre-cleared Predetermined Change Control Plan (PCCP) allows manufacturers to implement planned machine learning modifications without submitting a new 510(k). PMX OS operationalizes this statutory framework by encoding the three core elements of a PCCP directly into the graph schema: the Description of Modifications, the Modification Protocol, and the Impact Assessment. When data science teams retrain an algorithm (such as CardioSense Pro’s arrhythmia detection convolutional net v2.4 to v2.5), PMX OS automatically evaluates the retrained model weights against pre-authorized quantitative bounds (e.g., sensitivity ≥ 98.5%, edge MCU latency ≤ 180ms). If all criteria are satisfied, the system generates an audit-grade verification package and updates the DHF under internal change control.

PMX OS integrates post-market clinical telemetry ingesters that monitor distribution statistics of input feature vectors and prediction confidence scores in production. If real-world telemetry exhibits statistical divergence (e.g., increased false-positive arrhythmia classifications in pediatric cohorts or under specific stress conditions), PMX OS flags a "Telemetry Drift Alert." Crucially, the platform links this operational signal directly back to the active ISO 14971 risk management file, identifying the specific hazard and clinical probability assumption that has degraded. Quality and data engineering teams can immediately isolate whether the drift is caused by physical sensor degradation, demographic shifts, or algorithmic artifacts, triggering targeted retraining loops before clinical adverse events occur.

Medical software classified under EU MDR as Class IIa or higher automatically falls under the High-Risk AI System requirements in Annex I of the EU AI Act. PMX OS satisfies these mandates through automated graph controls aligned with Articles 9 through 15. The platform maintains complete dataset provenance under Article 10, tracking patient demographic stratification, raw biosignal lineage, and annotation protocol signatures. It maps continuous risk management under Article 9 to existing ISO 14971 files, auto-compiles Annex IV technical documentation under Article 11, and establishes documented human-in-the-loop oversight workflows under Article 14, enabling MedTech manufacturers to pass joint Notified Body MDR and EU AI Act conformity assessments without maintaining separate compliance systems.

Traditional 510(k) preparation involves assembling hundreds of pages of static comparison tables comparing a subject device to cleared predicates. The PMX Regulatory Intelligence Engine automates this by decomposing predicate devices into structured technological characteristics: intended clinical use, patient contact materials, power specifications, sensor modalities, and performance test baselines. When evaluating a subject device like CardioSense Pro against primary predicate K182901, PMX OS programmatically compares each parameter against public openFDA records and internal bench data. Any technological difference is instantly flagged alongside required non-clinical bench testing standards (e.g., ISO 10993 for biocompatibility or IEC 60601-1-11 for home-use safety), auto-generating defensible Substantial Equivalence comparison sections ready for eSTAR electronic submission.

PMX OS codifies the official FDA CDRH guidance document "Deciding When to Submit a 510(k) for a Change to an Existing Device" into an algorithmic decision tree linked to knowledge graph invariants. When change CHG-1024 was initiated to replace sensor S-18 with S-22, the engine automatically evaluated the statutory flowchart questions: Does the change alter indications for use? No. Does it introduce a new operating principle? No. Does verification test V-0183 prove that surface temperatures remain strictly below 41.0°C? Yes. Because no new risks were introduced and performance boundaries remained intact, PMX OS concluded that a new 510(k) was not required, automatically compiling an auditable Letter-to-File justification package complete with linked laboratory test evidence.

A major operational failure in global MedTech is releasing an engineering change that is permissible in one market but constitutes an illegal unnotified modification in another. PMX OS solves this through a multi-jurisdiction regulatory mapping matrix. When a component or firmware modification is evaluated, the platform runs simultaneous evaluations against FDA 510(k) rules, EU MDR Article 120 / MDCG 2020-3 Significant Change criteria, Japanese PMDA Minor Modification rules, and Health Canada annual update mandates. The dashboard displays a synchronized multi-country status bar, warning regulatory heads if an upcoming component swap will require prior Notified Body approval in Europe even while qualifying as an internal Letter-to-File in the United States.

PMX OS is architected from the database layer upward to satisfy FDA 21 CFR Part 11 and EU Annex 11 electronic records and signatures mandates. Every graph mutation—whether creating a requirement, modifying a risk score, approving a test protocol, or changing a component link—is recorded in an append-only, immutable cryptographic audit trail. Each entry captures the exact UTC timestamp, user identity, IP address, pre-modification and post-modification state deltas, and dual-credential electronic signatures. System audit logs cannot be edited, overwritten, or purged by administrators. Furthermore, all rendered regulatory export files include embedded SHA-256 cryptographic verification hashes, enabling external auditors to independently confirm document integrity and provenance.

PMX OS enforces end-to-end encryption across all system tiers. Data at rest is encrypted using AES-256 with customer-managed cryptographic keys (BYOK) stored in dedicated hardware security modules (HSM). Data in transit across all internal microservices and external webhooks is secured via TLS 1.3 with strict forward secrecy. Primexia is SOC 2 Type II certified across all five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy), ISO 27001 certified, and HIPAA compliant. For multinational enterprises with strict data sovereignty requirements, PMX OS offers guaranteed regional data residency across dedicated US, European Union (Frankfurt), and Asia-Pacific cloud zones, with zero cross-border data telemetry.

The platform enforces zero-trust architecture utilizing fine-grained Role-Based Access Control (RBAC) combined with Attribute-Based Access Control (ABAC). Access rights can be restricted by organizational division, product line, geographic jurisdiction, and clearance level. Furthermore, PMX OS incorporates automated data redaction and tokenization pipelines: clinical trial telemetry ingested for algorithm validation is stripped of Protected Health Information (PHI) before reaching the knowledge graph, while proprietary CAD models and electrical netlists can be ingested as structural topological metadata without storing raw geometric CAD binaries in the cloud, safeguarding your core IP.

A standard PMX OS deployment follows a structured 4-phase timeline spanning 8 to 12 weeks. Phase 1 (Weeks 1–2) focuses on architecture alignment, connector deployment, and connecting active Git repositories or PLM instances to map an initial device family like CardioSense Pro. Phase 2 (Weeks 3–6) configures automated schema extraction, establishes baseline requirement-to-risk trace links, and ingests historical verification test records. Phase 3 (Weeks 7–9) executes Computer Software Assurance (CSA) validation protocols, validates electronic signature workflows, and conducts end-user role training. Phase 4 (Weeks 10–12) achieves formal production release across R&D, RA, and QA teams, transitioning the organization to continuous live lifecycle intelligence.

Yes. While most customers take advantage of PMX OS Multi-Tenant or Dedicated Single-Tenant SaaS hosted in high-availability SOC 2 medical cloud environments, we offer complete deployment flexibility for defense-grade and high-security enterprise manufacturers. PMX OS is packaged as containerized Kubernetes (Helm) microservices that can be deployed into private customer-owned cloud VPCs on Amazon Web Services (AWS GovCloud / Commercial), Microsoft Azure (Azure Government), or Google Cloud Platform. For classified defense medical projects and sovereign infrastructure, PMX OS can be deployed in fully air-gapped on-premise hardware clusters with local licensing and offline regulatory rule caching.

To eliminate the multi-month validation burden traditionally associated with enterprise medical software, Primexia delivers a comprehensive, pre-executed Computer Software Assurance (CSA) Validation Suite with every production release. Aligned with FDA CDRH’s Computer Software Assurance guidance and GAMP 5 principles, our validation package includes the User Requirements Specification (URS), Functional Specification (FS), Software Design Specification (SDS), Risk Assessment (FMEA on software intended use), Pre-Executed Installation Qualification (IQ), Operational Qualification (OQ), and a customizable Performance Qualification (PQ) script with automated test execution evidence, drastically reducing internal QA validation cycles.

PMX OS communicates with PTC Windchill via Windchill REST Services (WRS) and with Siemens Teamcenter through Teamcenter Active Workspace and SOA endpoints. The connectors establish bi-directional event listeners: whenever an Engineering Change Order (ECO) is authored or a multi-level Bill of Materials (BOM) is revised, the connector parses part numbers, manufacturer datasheets, CAD assembly relationships, and material specifications. This structural information is normalized into the PMX Knowledge Graph, where it is instantly evaluated against system safety requirements and biological risk files. Conversely, PMX regulatory clearance status tags can be written back into Windchill or Teamcenter part attributes to prevent premature tooling releases.

For software and firmware engineering, PMX OS integrates directly into developer toolchains via GitHub Actions, GitLab CI/CD webhooks, and Atlassian Forge APIs. Developers link commits or pull requests to requirements by referencing requirement tags (e.g. [REQ-0184]) in commit messages or branch names. The PMX CI/CD bot runs an automated linter on every pull request, traversing the knowledge graph to verify whether code modifications impact safety-critical functions or IEC 62304 architecture classifications. If an unverified change is detected, the PR status check fails with a detailed blast radius report, preventing non-compliant code from merging into production release branches.

When procurement or supply chain logs an Engineering Change Notice or End-of-Life (EOL) tag in SAP S/4HANA (via OData APIs) or Oracle Cloud SCM (via OIC), PMX OS ingests the part number and queries the enterprise knowledge graph to locate all finished goods assemblies (UDI-DI) that consume that component. In the case of CardioSense Pro v3.8.2, an obsolescence notice on thermistor S-18 immediately triggered a graph query identifying 3 active manufacturing facilities, 12 country registrations, and requirement REQ-0184. Regulatory and quality leads receive automated notifications specifying which alternative parts have pre-existing verification data, eliminating weeks of uncoordinated email triage.

PMX OS employs a dual-engine architecture that strictly separates generative language drafting from deterministic knowledge graph verification. Large language models are never permitted to generate regulatory claims, risk classifications, or standard compliance assertions autonomously. Instead, every AI-assisted draft is generated via Graph-Constrained Retrieval-Augmented Generation (GCRAG): the model is provided with an explicit subgraph context of verified entities, requirements, and test logs. Before any output is displayed to the user, an automated validation linter checks that every single statement, citation, and parameter is mathematically bound to a specific, cryptographically verified node in the active graph, guaranteeing zero hallucinations.

Dataset governance is managed via specialized Dataset Nodes within the knowledge graph. When training files—such as 10,000 raw ECG Holter waveforms—are ingested for algorithm training, PMX OS calculates cryptographic SHA-256 hashes of the raw signal files, the clinical annotation protocol, the clinician annotator identities, and the demographic stratification metadata. The graph explicitly records the training/validation/test splits to ensure that data leakage cannot occur. When model weights are committed, they are immutably bound to these dataset nodes. During an FDA inspection or Notified Body audit, the manufacturer can trace backwards from any model parameter directly to the verified clinical patient waveforms.

PMX OS is built on a distributed, high-concurrency graph database engine optimized for complex topological traversals and sub-second dependency queries. The persistence layer combines native graph storage (with index-free adjacency) for entity relationships with an immutable time-series event log for 21 CFR Part 11 audit trails. Relational metadata is indexed across memory-optimized cache tiers, allowing the Change Simulator to evaluate 50,000 multi-hop dependencies across hundreds of device configurations in under 350 milliseconds. The architecture scales horizontally across clustered nodes, supporting enterprise portfolios containing tens of millions of active requirements, components, risks, and test records without performance degradation.

Acquiring new medical device companies frequently leaves parent organizations with an unmanageable patchwork of acquired legacy QMS databases, isolated file shares, and local PLM installations. Attempting to force all acquired business units into a single monolithic PLM takes years and costs tens of millions. PMX OS solves this through federated knowledge harmonization. Connectors ingest data from acquired systems without shutting them down, mapping disparate part naming conventions, risk scales, and requirement taxonomies into a unified enterprise ontology. Executive leadership gains single-pane portfolio visibility, common quality metrics, and synchronized regulatory monitoring across all divisions immediately post-acquisition.

Traditional audit preparation consumes hundreds of staff hours as quality teams pull binders, reconcile broken links in Excel matrices, and draft explanatory memos for auditor inquiries. With PMX OS, audit defense is transformed into a real-time interactive cockpit. When an auditor asks to see evidence that a specific post-market complaint was investigated and tied to risk mitigation and design verification, the quality lead queries the graph. The system displays the entire causal chain from complaint intake to CAD revision, test protocol execution, and electronic sign-off in seconds. Auditors are provided with cryptographically verified, read-only audit dossiers, eliminating findings caused by missing documents or broken trace links.

PMX OS computes quality governance metrics dynamically through continuous topological graph analysis rather than static manual status reports. The System Readiness Score (e.g. 91/100 for CardioSense Pro v3.8.2) evaluates graph completeness across three statutory dimensions: 100% User Need Coverage verifies that every clinical need maps to at least one verified design input; Hazard Mitigation Coverage confirms that all ISO 14971 risk nodes possess verified risk control measures; and Active Verification Delta flags nodes with pending laboratory tests (such as V-0183 under CHG-1024). Any orphan requirement or broken trace link immediately degrades the readiness score, giving quality executives an objective, real-time index of submission defensibility.