Regulatory Framework
ISO 13485:2016 is published by the International Organization for Standardization and is the third major revision of the standard since its 1996 origin. The 2016 revision strengthened the risk-based approach throughout the QMS, expanded supplier-control requirements, introduced explicit software validation expectations, and aligned with the structural conventions of ISO 9001:2015 while remaining a standalone medical-device standard. The standard is recognized by the International Medical Device Regulators Forum (IMDRF) and is the basis of the Medical Device Single Audit Program (MDSAP), through which a single audit satisfies regulators in Australia (TGA), Brazil (ANVISA), Canada (Health Canada), Japan (MHLW/PMDA), and the United States (FDA).
Under the EU MDR, ISO 13485 conformity is the practical pathway to CE marking for all device classes that require notified-body involvement (Class Is, Im, Ir, IIa, IIb, and III). Annex IX (conformity assessment based on a quality management system and on assessment of technical documentation) presupposes a functioning QMS that meets the harmonized standard. The MDR introduces post-market surveillance obligations under Articles 83-86 (PMS plan, PMS report, periodic safety update report), vigilance obligations under Articles 87-92 (incident reporting, field safety corrective actions), and Unique Device Identification (UDI) obligations under Articles 27-28, all of which generate continuous evidentiary demand on the QMS.
ISO 14971:2019 binds the QMS to a lifecycle risk-management process that explicitly contemplates post-production information as input to risk control. The recently published technical reports, ISO/TR 24971:2020 (guidance on the application of ISO 14971) and AAMI TIR57 / IEC 81001-5-1:2021 (security activities in the lifecycle of health software), bring cybersecurity into the QMS scope, and the FDA's September 2023 final guidance on premarket cybersecurity for medical devices makes SBOM provision and post-market vulnerability monitoring explicit conditions of marketing authorization. The QMS, once a paper-driven discipline, is now a continuous-evidence discipline.
Architectural Requirement
The architectural requirement implicit in ISO 13485 and its surrounding regulatory ecosystem is a continuous, attestable evidence substrate for the fielded device fleet. Clause 7.3 (Design and Development) requires design output to be verified and validated against design input, with traceability maintained through the lifecycle: for software-of-medical-device and connected devices, validation is not a one-time gate but a continuous obligation as firmware, model weights, and configuration evolve. Clause 7.5.6 (Validation of processes for production and service provision) and Clause 7.5.9 (Traceability) extend the obligation into manufacturing and field service.
Clause 8.2.1 (Feedback) mandates that the manufacturer establish documented procedures for a feedback process that "shall provide for the collection and monitoring of information generated from production as well as post-production activities." Clause 8.2.3 (Reporting to regulatory authorities) and Clause 8.5.2 (Corrective action) bind that feedback to mandatory reporting and remediation timelines that are measured in days, not quarters. For a connected infusion-pump fleet of 50,000 devices distributed across 1,200 hospitals, satisfying these clauses without a fleet-health primitive is a logistical fiction.
ISO 14971 risk control measures are evaluated in light of post-production information, Clause 10 explicitly requires that the manufacturer review post-production information for relevance to safety, with a feedback loop into the risk-management file. The combined effect of Clause 8.2.1 (ISO 13485) and Clause 10 (ISO 14971) is an architectural mandate: the manufacturer must have an evidentiary stream from each fielded device sufficient to support timely safety reassessment. UDI traceability under MDR Article 27 makes per-device evidence not just useful but legally required.
Why Procedural and Bolt-On Compliance Fails
Procedural QMS implementations satisfy the documentation-of-procedures letter of ISO 13485 while failing its evidentiary spirit. A typical post-market surveillance procedure references "complaint logs," "service records," and "literature review" as inputs, all of which are curated artifacts produced after the fact by humans. When a regulator asks during inspection what the firmware version was on the specific pump that delivered an over-infusion two months ago, a complaint-log answer is insufficient, the manufacturer needs cryptographically-grounded device-state evidence at the moment of the event.
Bolt-on telemetry, vendor cloud connectors, hospital-side EHR integrations, retrofitted device-management platforms, produces evidence that is not bound to the regulated device under either ISO 13485 software-validation expectations or the FDA's premarket cybersecurity guidance. The integration itself is generally not within the validated state of the device, and the data it produces is therefore unreliable as input to CAPA, vigilance reporting, or MDR Article 87 incident reporting. FDA Form 483 observations and EU notified-body nonconformities in this category turn on the same recurring deficiency: the inability of bolt-on stacks to produce per-device firmware and configuration evidence that is bound to the regulated device at the moment of an event.
Recall management exposes the failure most starkly. When a manufacturer determines that a firmware version requires field correction under MDR Article 95 or 21 CFR Part 806, the population to be corrected must be enumerated and the correction status tracked. Without architectural fleet-health attestation, the population is reconstructed by querying customers, and the evidence of correction is a checkbox on a service ticket rather than a verifiable measurement.
What The AQ Primitive Provides
The health-monitoring primitive provides the architectural substrate that ISO 13485, ISO 14971, MDR, and the FDA QMSR collectively demand. Each device establishes identity through continuity-based device identity rather than enrollment with a central certificate authority: each device computes a dynamic device hash from device-specific entropy, sensor readings, configuration state, clock state, and the content of prior transmissions, and attaches that hash to every governed observation it emits. The hash evolves gradually in a way that reflects the device's genuine operational state over time, and each receiving party evaluates a newly received hash against the recorded history of that device to compute a trust-slope metric. Spoofing and replay are detected as discontinuities in the hash sequence, so a stolen static credential is insufficient to impersonate a genuine device. This continuity-based identity is the per-device anchor to which UDI-DI tracking under MDR Article 27 and 21 CFR 830 can be bound. Tamper-evident sealing produces governed tamper observations on physical interference, and firmware updates, configuration baselines, and runtime integrity are tracked as lineage-recorded attestations, satisfying the software-validation and traceability obligations of Clauses 7.3 and 7.5. A device may also carry a physical-unclonable-function challenge-response monitor as one of several health observations, producing observations of PUF-response consistency that feed the same governed evidence stream.
SBOM attestation closes the cybersecurity gap that the FDA's premarket cybersecurity guidance and IEC 81001-5-1 introduced into the QMS scope. A governance-credentialed software bill of materials is carried in device lineage and verified by the SBOM attestation verifier, producing a chain from upstream dependency through the regulated firmware build into the field-deployed device. Because the manufacturing-provenance chain and the SBOM are evaluated as governed observations against the device-to-manufacturer attestation chain, when a vulnerability is disclosed in an upstream dependency the manufacturer can query the affected device population directly from the evidence substrate rather than reconstructing it by hand, supporting the vigilance timelines under MDR Article 87.
Zero-trust device management operationalizes the access-control and configuration-management expectations of the QMS at the fleet level. Every command issued to a fielded device, whether a parameter change, a software update, or a diagnostic readback, is evaluated against the device's current attestation state, the requesting clinician's or service technician's credentials, and the policy in force. The credential lifecycle supports enrollment, rotation, and revocation of authority credentials: when a credentialing authority emits a revocation governed observation identifying a specific device, credential, or credential class as no longer authoritative, each consuming device down-weights or invalidates previously admitted observations, including over a specified past-effect window. This propagated revocation is the field-correction mechanism that recall management requires.
The primitive composes with the platform's five-property governance chain, in which every governed mutation carries authority-credentialed observation, evidential weighting in a shared observation store, composite admissibility evaluation across cognitive-domain fields, governed actuator execution, and lineage-recorded provenance. Because every attestation passes through this chain, it becomes a first-class evidentiary record with a credentialed source, an admissibility evaluation, and a deterministic lineage suitable for FDA inspection, notified-body audit, MDSAP review, and product-liability litigation. That composition is what allows post-market surveillance to operate as a continuous, defensible discipline rather than a periodic paper exercise.
Compliance Mapping
The primitive maps directly onto ISO 13485:2016 clauses: 4.1.6 (validation of QMS software) and 4.2.5 (control of records) are satisfied by the cryptographically-anchored attestation log; 7.3.6 (design and development verification) and 7.3.7 (design and development validation) are supported by continuous post-deployment measurement; 7.5.6 (validation of processes for production and service provision), 7.5.9 (traceability), and 7.5.11 (preservation of product) are satisfied by per-device identity and integrity attestation; 8.2.1 (feedback), 8.2.3 (reporting to regulatory authorities), 8.3 (control of nonconforming product), 8.4 (analysis of data), 8.5.2 (corrective action), and 8.5.3 (preventive action) all draw on the same evidentiary stream.
Against ISO 14971:2019, the primitive feeds Clause 10 (production and post-production activities) with verifiable post-production information, supporting risk-control reassessment with primary evidence rather than aggregated complaint statistics. Against MDR, the primitive supports Articles 83-86 (post-market surveillance), 87-92 (vigilance), and 27-28 (UDI), and against IVDR it supports the parallel obligations under Articles 78-81 and 82-87.
Against FDA regulations, the primitive aligns with 21 CFR Part 820 / QMSR, 21 CFR Part 803 (medical device reporting), 21 CFR Part 806 (corrections and removals), 21 CFR Part 820.30 (design controls), and the September 2023 premarket cybersecurity guidance for SBOM and post-market vulnerability monitoring. Across MDSAP jurisdictions the same evidence stream serves Health Canada SOR/98-282, TGA Therapeutic Goods (Medical Devices) Regulations 2002, and PMDA MHLW Ministerial Ordinance 169.
Adoption Pathway
Adoption begins with newly designed devices entering the regulatory pipeline: continuity-based identity, the attestation and tamper-observation infrastructure, and governance-credentialed SBOM are integrated into the design controls under Clause 7.3, validated as part of the Design History File, and submitted as part of the premarket package under FDA 510(k), De Novo, or PMA pathways and the MDR technical documentation. This places the fleet-health substrate inside the validated state of the device from the outset.
Existing fielded fleets are migrated through firmware updates that introduce attestation capability and enroll devices into the identity registry. Migration is sequenced by risk class, Class III implantables and Class IIb infusion / radiation devices first, Class IIa connected diagnostics next, with field-service and complaint-handling workflows reconfigured to consume attestation evidence as the primary input to CAPA and vigilance.
Final-state deployment positions the manufacturer to satisfy MDSAP, MDR notified-body, FDA inspection, and global vigilance obligations from a single queryable evidence substrate, transforming post-market surveillance from a periodic compliance burden into a continuously defensible safety practice.
Disclosure Scope
This article is a general-application disclosure of the fleet health-monitoring layer of the spatial mesh applied to medical-device quality management. The named regulatory standards and frameworks (ISO 13485:2016, ISO 14971:2019, ISO/TR 24971:2020, AAMI TIR57, IEC 81001-5-1:2021, EU MDR 2017/745, EU IVDR 2017/746, FDA 21 CFR Parts 803, 806, 820 and the QMSR, and the MDSAP jurisdictional regulations) are the property of their respective bodies and are described here only to situate the application. The underlying technology, including continuity-based device identity, the dynamic device hash and trust-slope validation, lineage-recorded health and tamper observations, governance-credentialed software bill of materials and manufacturing-provenance attestation, the authority-credentialing and credential-revocation lifecycle, fleet health aggregation, and the five-property governance chain, is disclosed in U.S. Provisional Application No. 64/049,409. Implementation specifics for any particular device class, clause mapping, or deployment topology are illustrative embodiments and may be varied without departing from the disclosed invention.
