Medical Device and SaMD Architecture
Consequential Data Engineering
Software architecture for medical devices and Software as a Medical Device, built so a Class C fault cannot reach a Class A component and every ISO 14971 risk control traces to a passing test. We deliver the architecture record, the SOUP register and a CycloneDX SBOM that feed the sponsor's premarket submission under FD&C Act §524B.
The Customer Problem: Four Device Software Failure Patterns
Class C faults reaching Class A code
The dose calculation and the settings screen share a process and its memory. The whole program is then Class C, and a crash in the screen can corrupt a safety-relevant value.
Cloud latency inside a clinical decision
A therapy or alarm decision waits on a cloud round trip. Network delay becomes part of the safety argument, and nobody has measured its tail.
Medical API drift
Device and cloud versions drift apart, and an unversioned or unauthenticated endpoint keeps accepting requests from builds that were never verified together.
Untraced SOUP and COTS
Open-source libraries arrive through a package manager. No SOUP record says which version is in the build, why it is acceptable, or which software item depends on it.
The Consequential Solution: Architecture That Carries the Safety Argument
- Segregation where the hazard is. The software items that implement risk controls are separated from the rest by process, memory protection or hardware, with the rationale IEC 62304 §5.3.5 asks for, so items outside the boundary can carry their own safety class.
- Clinical decisions stay local. A decision on a hazard path runs on the device or the bedside gateway; the cloud receives the record and is not in the loop.
- Every control traced to a passing test. ISO 14971:2019 hazards, risk controls and verification results are rows in SQLite, so an untested control is a query result before it is an audit finding.
| Class | Harm the software can contribute to | What segregation changes |
|---|---|---|
| A | No injury or damage to health | Items shown to be outside every risk-control path can stay here |
| B | Non-serious injury | More lifecycle activities apply than for Class A |
| C | Death or serious injury | Kept as small as the hazards allow, since its verification is the most demanding |
The activities each class requires are listed clause by clause in the IEC 62304 practical guide.
Design and change controls for these items follow ISO 13485:2016 clause 7.3, which the FDA QMSR (21 CFR 820, in force since 2 February 2026) incorporates by reference in place of the former §820.30. See the FDA QMSR guide.
What Netspective Delivers: Engineering Responsibility
Architecture record and segregation rationale
Software items, their safety class, the interfaces between them and the segregation behind each class, kept as reviewed Architecture Decision Records.
Risk traceability database
ISO 14971:2019 hazards, risk controls and verification results as SQLite tables, with the gap queries your QA team re-runs before each release.
SOUP register and SBOM
A CycloneDX SBOM generated by the build and a SOUP record per component: version, purpose, the anomaly list reviewed, and the software items that depend on it.
Risk management follows the ISO 14971 guide, design controls the FDA QMSR guide, and SOUP replacement the legacy modernization practice. Test evidence can run through Test Management as Code.
Mechanics and System Contracts
- DeviceClass C items in their own process
- Bedside or edge gatewayWhere hazard-path decisions run
- Versioned APIMutual TLS; unverified pairings refused
- Cloud backendRecords and analytics, out of the decision loop
- Traceability databaseHazards, controls, tests and SOUP in SQLite
Interfaces and their contracts
| Interface | Contract | Checked by |
|---|---|---|
| Class C item to Class A display | Separate processes; values cross as validated messages, never shared memory | A fault-injection test: stop the display, the Class C item keeps running |
| Device to cloud API | Mutual TLS and versioned endpoints; a build pairing that was never verified together is refused | Contract tests per version pair |
| Clinical decision path | Runs on the device or gateway; losing the cloud drops to a defined safe mode | A network-loss test |
| Build to SOUP | Every dependency pinned and listed in the SBOM | The SOUP gap query (Panel 2) |
| Risk controls to tests | Each control linked to the tests that verify it | The trace gap query (Panel 3) |
For a cyber device under FD&C Act §524B, the same records supply the SBOM the statute requires and the threat model and security architecture views FDA's premarket cybersecurity guidance recommends. The sponsor files them.
SBOM and Traceability Explorer
Three steps a reviewer can re-run. Each panel says whether it is a public command or a synthetic illustration, and every query is SQLite.
Panel 1: Generate the SBOM from the build
Produce a CycloneDX software bill of materials from the build output, then open a scratch SQLite database next to it.
# Generate a CycloneDX SBOM for the build output
syft scan dir:./build -o cyclonedx-json > sbom.cdx.json
# Open a scratch database beside it and run the query in Panel 2
sqlite3 soup-review.db
Public command Writes: sbom.cdx.json. Syft is an open-source SBOM generator (Apache-2.0). An SBOM lists what is in the build; it does not evaluate it. That is the SOUP record's job.
Panel 2: Components with no SOUP evaluation
Every component in the SBOM that has no evaluation on record: the list your SOUP review starts from.
-- Synthetic illustration: SBOM components with no SOUP evaluation on record
-- (IEC 62304 §8.1.2 identifies SOUP; the evaluation is your risk file's job).
-- Reads a CycloneDX file with the sqlite3 shell's readfile(); the evaluation
-- register is a TEMP stand-in, so nothing is written.
CREATE TEMP TABLE IF NOT EXISTS soup_evaluation (
name TEXT NOT NULL, version TEXT NOT NULL, safety_class TEXT NOT NULL,
evaluated_by TEXT NOT NULL, PRIMARY KEY (name, version)
);
SELECT json_extract(c.value, '$.name') AS component,
json_extract(c.value, '$.version') AS version,
json_extract(c.value, '$.purl') AS purl
FROM json_each(readfile('sbom.cdx.json'), '$.components') AS c
LEFT JOIN soup_evaluation e
ON e.name = json_extract(c.value, '$.name')
AND e.version = json_extract(c.value, '$.version')
WHERE e.name IS NULL
ORDER BY component;
Synthetic illustration readfile() is a function of the sqlite3 shell, so run this there, in the folder holding the SBOM. The evaluation register is an illustrative TEMP table, not a product schema. Runs as written in SQLite 3.
Panel 3: Risk controls with no passing test
ISO 14971 risk controls implemented in software that no passing verification test covers yet, highest safety class first.
-- Synthetic illustration: ISO 14971 risk controls with no passing
-- verification test linked to them.
CREATE TEMP TABLE IF NOT EXISTS hazard (hazard_id TEXT PRIMARY KEY, description TEXT NOT NULL);
CREATE TEMP TABLE IF NOT EXISTS risk_control (
control_id TEXT PRIMARY KEY, hazard_id TEXT NOT NULL REFERENCES hazard(hazard_id),
software_item TEXT NOT NULL, safety_class TEXT NOT NULL CHECK (safety_class IN ('A','B','C'))
);
CREATE TEMP TABLE IF NOT EXISTS verification_result (
test_id TEXT NOT NULL, control_id TEXT NOT NULL REFERENCES risk_control(control_id),
outcome TEXT NOT NULL CHECK (outcome IN ('pass','fail')), run_utc TEXT NOT NULL
);
SELECT h.hazard_id,
rc.control_id,
rc.software_item,
rc.safety_class
FROM risk_control rc
JOIN hazard h ON h.hazard_id = rc.hazard_id
WHERE NOT EXISTS (
SELECT 1 FROM verification_result v
WHERE v.control_id = rc.control_id AND v.outcome = 'pass'
)
ORDER BY rc.safety_class DESC, h.hazard_id;
Synthetic illustration TEMP stand-ins; nothing is written. On a real traceability database, drop the CREATE TEMP TABLE lines. An empty result is a check, not a verdict: the reviewer still reads the tests. Runs as written in SQLite 3.
Verified Proof Ledger (Engineering Ground Truth)
What each claim on this page rests on. No row is marked as tested until it cites a recorded run, and none does yet: this practice's engagement records are not published.
| Claim | Status | What it rests on |
|---|---|---|
| Software safety classification and segregation rationale (IEC 62304 §4.3, §5.3.5) | Designed and documented | The IEC 62304 practical guide on this site; delivered per engagement. No recorded run yet. |
| ISO 14971:2019 hazard, risk control and test traceability in SQLite | Designed and documented | The pattern shown in the explorer; built per engagement. No recorded run yet. |
| CycloneDX SBOM and SOUP register from the build | Designed and documented | Open-source tooling (Syft) and the legacy-modernization and SOUP practice on this site. No recorded run yet. |
| Premarket cybersecurity documentation inputs (FD&C Act §524B) | Designed and documented | Drafted per engagement against FDA's premarket cybersecurity guidance; the sponsor owns and files the submission. |
| FDA clearance, approval or a notified-body certificate | Not established | FDA and notified bodies decide. We claim no outcome. |
| Changes that skip regression verification of unaffected items | Not established | Segregation narrows what a change touches; the change impact analysis and its verification still run. |
Typical Engagements
These describe the shape of an engagement in each setting. They are not named client results.
SaMD cloud backend for a Class II device
A device that uploads therapy records: decision logic stays on the device, the cloud API is versioned and mutually authenticated, and one SBOM covers both sides for the 510(k) cybersecurity documentation.
Dosing software: Class C isolation
Dose calculation separated from the user interface by process and memory boundaries, so the interface can be classified on its own with a documented segregation rationale.
A SOUP backlog before a submission
A codebase with hundreds of transitive dependencies: the SBOM and the gap query turn the SOUP review into a ranked list, highest safety class first.
Scoped Pilot: The 2-Week SaMD Architecture Sprint
What the two weeks deliver
Week 1: classify and segregate
Read the architecture, hazard analysis and dependency list, classify the software items, and draft the segregation rationale.
Week 2: trace and hand over
Generate the SBOM, run the SOUP and trace gap queries, and hand over the architecture record and the ranked gap list.
Boundaries
- Software safety classification is the manufacturer's decision; we draft the rationale for your team to review and approve.
- We do not file submissions or represent you to FDA or a notified body.
- The sprint needs design documents and the build, never patient data.
- This is engineering work, not regulatory counsel.