You’re Not Shipping a Device. You’re Shipping a Node in Someone Else’s Network.
Regulatory strategy for connected and interoperable devices — interface risk, wireless coexistence, and the postmarket duties that begin the day your product joins a hospital network.
The Bench Can’t See the Hospital.
A connected device is verified on a quiet bench and deployed into a building with two thousand Wi-Fi clients, an EHR mid-migration, a biomed department with its own patch policy, and a network team that has never read your IFU. Every interface you expose — to other devices, to the record, to the cloud, to the user’s phone — is a place where someone else’s engineering becomes your clinical risk.
FDA’s interoperability guidance made the expectation explicit: characterize each interface, state what it’s for and who may use it, and carry the interactions through your risk file. We treat interfaces as product — specified, risk-analyzed, verified, and versioned — because that is exactly how the reviewer, and the incident investigator, will treat them.
Your device joins whatever is already on the ward — pumps, monitors, phones, and a network you’ve never seen.
Four Interfaces, Four Rulebooks, One Risk File.
Every connection your device makes has its own standards, its own failure modes, and its own place in the submission.
Device ↔ Device
Command, control, and data exchange between instruments — where a malformed message from a partner device becomes your hazard analysis’s problem.
Device ↔ Record
The clinical value and the integrity risk: units, timestamps, patient matching, and what happens downstream when a value lands in the wrong chart.
Device ↔ Cloud
Availability becomes a safety property. If therapy or alarms depend on a service, its outage modes belong in the 14971 file, not the SLA appendix.
Device ↔ Spectrum
Wireless coexistence in a hostile RF environment — tested to recognized methods, with degradation behavior that fails safe when the spectrum doesn’t cooperate.
The boundary questions ride along: is the companion app an accessory with its own classification, is the data pipe a low-risk MDDS or part of the device, and which functions does the cloud actually perform? Those calls set the scope of the submission — we make them first, on paper.
Nobody guarantees your device bandwidth. The file has to show what happens when it doesn’t get any.
Every Patch Is a Change-Control Decision, Not an IT Ticket.
Connectivity turns maintenance into a regulatory activity. The OS update that recertifies nothing, the TLS library bump, the EHR vendor’s API change, the cloud migration — each one either stays inside your verified envelope or it doesn’t, and someone with design-control authority has to make that call on the record.
The good news: done right, this is a governance procedure, not a submission generator — routine security and compatibility patches rarely need new clearances. The discipline is proving that determination was made, patch by patch, by a process the auditor can read.
What a Connected Program Plans Around.
Three expectations that define the category’s evidence bar.
Characterized, purposed, and risk-analyzed — the anticipated users and uses of each connection, stated in the file.
Wireless performance proven in contested spectrum, with defined degradation behavior — not assumed from a clean-lab pass.
The design principle regulators reward: when the network drops, the clinician knows — silence is the one failure mode you can’t defend.
Six Failure Modes We Are Brought In to Prevent.
Interoperability failures rarely present as device failures — they present as clinical mysteries.
Interfaces missing from the risk file
A 14971 analysis that ends at the enclosure, while the product’s actual value — and hazard — lives in the connections.
Coexistence tested in silence
A clean-lab wireless pass presented for a device headed to an ICU with hundreds of competing radios.
Cloud outage as an afterthought
Therapy-relevant functions dependent on a service whose failure modes never met the hazard analysis.
Undeclared interfaces, used anyway
Hospitals integrate whatever ports exist. If you didn’t characterize it, you still own what happens over it.
Alarm forwarding assumed reliable
Escalation chains built over consumer messaging infrastructure, with nobody accountable for the dropped packet at 2 a.m.
Patching around design controls
A fleet-update pipeline that ships to production devices faster than the quality system knows about it.
Connected-Device Regulatory Leadership That Reads Network Diagrams.
Our leads have characterized interfaces for submissions, defended coexistence data, and built patch governance that survives audits.
“Interoperability failures don’t look like device failures — they look like clinical mysteries. The file has to prove you engineered for a network you don’t control.”
The discipline we bring to pumps, monitors, gateways, and everything they talk to.
Connecting a Device to the Clinical Network? Engineer the Interfaces Like Product.
Bring senior connected-device leadership in before the first integration request — not after the first mystery.
Senior-led. Embedded in your team. No junior hand-offs.