1. Start with a benefit worth supporting
Connectivity can reduce transcription, support servicing or enable a new clinical workflow. It also adds interfaces, dependencies, failure modes and continuing obligations. Decide what problem it solves before choosing Bluetooth, Wi-Fi or a cloud platform. A cable, a local docking station or keeping the product standalone may better meet the need.
By the end of this module, you should be able to define a connected function, identify the additional work across disciplines, write failure and recovery requirements, and explain what evidence and support are needed before release.
The MTL-140 learning pathway remains a standalone, locally operated device. Here we explore a hypothetical new variant that exports completed treatment records to a hospital system. The initial proposal does not change infusion settings remotely and does not provide a remote alarm service. There is no AI.
Define the records, intended recipient, timing and permitted clinical use. If clinicians will rely on them for subsequent treatment decisions, analyse that use explicitly. Calling a feature “for information only” does not resolve foreseeable reliance.
Exercise 1 · Write the connectivity claim
In five sentences state the benefit, users, exchanged information, permitted actions and what must remain available when disconnected. Add one measurable success criterion and two exclusions.
Compare your approach
After local completion of an infusion, the proposed pump exports an identified treatment record to an authorised hospital endpoint, reducing manual entry. Local operation and alarms do not depend on export. Remote programming and remote alarm delivery are excluded. Measure successful reconciliation and transcription errors in a representative workflow; agree justified acceptance criteria before testing. The exported record’s permitted clinical use and patient association remain explicit design inputs.
2. Different connections bring different responsibilities
| Proposed function | Additional questions | Evidence to plan |
|---|---|---|
| Export completed records | Correct patient, device, units, time and destination? Missing or duplicated records? | Identity, mapping, integrity and reconciliation tests. |
| Remote status or monitoring | How old is the display? Who notices loss of monitoring? Is it part of an alarm response? | Latency, stale-state, outage and representative user-workflow evidence. |
| Import settings or remote control | Who has authority? Which device receives the command? What happens after a timeout or conflicting local action? | Command validation, authorisation, arbitration, replay prevention and safety validation. |
| Remote software updates | How are packages authorised? When is installation safe? How is interruption recovered? | Authenticity, compatibility, power-loss recovery and controlled deployment evidence. |
On smaller screens, scroll the table sideways to view all columns.
These are different design scopes, not a mandatory maturity ladder. A record-export feature is not permission to add remote control later without change assessment. An application-level outbound data flow can still involve inbound acknowledgements, configuration and protocol traffic; document the real attack surface.
3. Design the whole system and its boundaries
Draw the device, communications subsystem, gateway or app if needed, receiving system, network services, service tools and users. Mark data flows, trust boundaries, ownership and dependencies such as identity, certificates and time. Cloud hosting is an architectural option, not a prerequisite for connectivity.
- Protect therapy: prevent network traffic, connection storms or a failed communications task from starving delivery control, local alarms or the user interface. Define and verify resource limits and isolation.
- Choose the transport: compare wired Ethernet or USB, short-range radio, Wi-Fi and cellular against range, mobility, throughput, power, environment, installation and lifetime cost. A wired interface still brings cybersecurity and integration work.
- Define degraded operation: identify what continues locally, what becomes unavailable and what the user sees. Disconnection does not automatically mean stopping therapy; the response needs clinical and risk justification.
- Allocate responsibility: agree who configures infrastructure, onboards devices, maintains credentials, supports integration and investigates incidents.
For the teaching variant, the design aim is to keep infusion control local and isolate export failures. A gateway may simplify hospital integration while adding another maintained component. Assess both options against the same requirements.
4. The physical product changes too
A communications module affects more than the schematic. Antenna location, enclosure material, nearby motors and cables, grounding, heat, power peaks and battery runtime can change performance. A wired connector brings ingress, cleaning, mechanical wear, electrostatic-discharge and electrical-isolation questions.
For wireless designs, plan RF performance, coexistence and electromagnetic-compatibility evaluation in the intended environment. Assess country-specific radio approvals and labelling with a competent specialist. A module’s existing certification can support the assessment but does not establish compliance of the complete product or its clinical performance.
Manufacturing must provision unique identities and credentials securely, control radio and firmware variants, verify the interface and prevent test credentials reaching released units. Service procedures must handle replaced boards, new identities and secure retirement of old hardware. Capture these activities in design transfer and supplier agreements.
5. Extend safety, cybersecurity and privacy work together
Ask how connection behaviour could contribute to harm: a record assigned to the wrong patient; stale status interpreted as current; a retry creating duplicate clinical entries; malicious traffic delaying local alarms. Analyse ordinary faults, foreseeable misuse and deliberate attacks, including effects on multiple devices.
Threat modelling should inform requirements for authenticated endpoints, least privilege, protected communications, input validation, secure configuration, updates, logging and credential lifecycle. Encryption alone does not establish correct identity, authorisation or availability. Analyse dependencies and maintain a software component inventory, including third-party communications libraries.
Minimise transmitted personal data, define access and retention, and decide who is responsible for processing it. Map these decisions to applicable privacy obligations for the intended markets and deployment. Keep safety risk, security risk and privacy assessments linked while retaining their distinct acceptance decisions.
Exercise 2 · Follow one failure to its consequence
The hospital receiver is unavailable during several treatments. On reconnection, one record appears twice and another is associated with the next patient. Identify causes, potential harm, design controls and evidence.
Compare your approach
Investigate unstable record identifiers, retry behaviour and reassignment of patient context. Bind each record to its original treatment and verified identity; use stable identifiers and duplicate-safe processing; retain an acknowledged delivery state. Test retries, reboots, patient changes and reconciliation end to end. Evaluate the harm from downstream use of incorrect records rather than treating successful transmission as sufficient.
6. Specify more than “send the data”
The interface contract must cover meaning and behaviour: identity, units, precision, timestamps and time quality, schema versions, authentication, error responses and delivery semantics. A transport acknowledgement may only mean that bytes arrived, not that a clinical record was accepted and filed.
- Offline: define buffer capacity, retention, full-buffer behaviour, visibility and any effect on new treatments.
- Uncertain delivery: define retry limits, stable record IDs, duplicate handling and reconciliation after lost acknowledgements.
- Reconnection: re-establish trust, check compatibility and reconcile pending records without replaying treatment actions.
- Invalid or stale data: reject or quarantine it with an actionable indication; never silently reinterpret units or identity.
- Usability: distinguish connection, transfer and acceptance states. Make pairing and patient association understandable and recoverable.
Illustrative requirement: after a receiver accepts a treatment record but its acknowledgement is lost, retransmission using the same record identifier shall not create a second clinical entry in the supported receiving configuration. Retain device and receiver evidence. Timing and storage limits must be separately justified; this example does not set clinical acceptance thresholds.
Use MTL-111 — Data, connectivity and interoperability for deeper information modelling, interface contracts and partner compatibility.
7. Verify the connected system and validate the workflow
Retain existing device evidence where a documented impact assessment supports it. Revisit affected hardware, software, risk controls, usability and performance. Identify exact device, gateway, server, schema and configuration versions in each test baseline.
- Test end-to-end meaning and identity with representative supported receivers, not only a simulated successful connection.
- Inject delays, loss, duplication, reordering, malformed messages, incompatible versions, expired credentials, unavailable time services and interrupted updates.
- Test full queues, repeated reconnects and high traffic while checking therapy performance, local alarm response, CPU, memory and battery behaviour.
- Perform security verification, including justified robustness and penetration testing, and resolve findings through controlled risk assessment.
- For wireless designs, evaluate interference, coexistence, coverage and mobility in representative conditions.
- Validate setup, patient association, disconnected operation and recovery with intended users. If remote alarms are in scope, validate the complete alarm-response workflow.
Assess regulatory change implications for each intended market before committing to release. Connectivity does not automatically assign a particular medical-device class, and a certificate for a radio or cloud service does not replace product evidence.
Exercise 3 · Write an adverse-condition test
Write a test for loss of the receiver acknowledgement after successful acceptance. Include the baseline, setup, injected failure, expected local and remote behaviour, acceptance criteria and retained evidence.
Compare your approach
Use an identified treatment record and controlled receiver configuration. Drop only the return acknowledgement after acceptance, then allow retry and reboot the pump at a defined point. Confirm one clinical entry, preserved identity and values, consistent delivery-state recovery and unaffected local therapy functions. Retain logs and receiver records linked to the requirement. Define the permitted completion time and retry behaviour before execution.
8. Release begins a continuing service commitment
Publish supported configurations, network requirements, installation and acceptance checks, roles and residual limitations. Plan credential renewal and revocation, vulnerability intake, component monitoring, patch assessment, incident response and compatibility changes. If you operate a server, also fund monitoring, backup, restoration tests, capacity and availability support.
Define the support period and responsibilities contractually. Hospital infrastructure, mobile operating systems, suppliers and network services may change faster than the device. Plan migration and end of support, including record access, secure deletion and safe local operation where the design supports it. A lost supplier or expired certificate must have an owned response.
9. Make the additional work visible in the plan
| Work package | Typical lead | Reviewable output |
|---|---|---|
| Benefit, scope and change assessment | Product, clinical and regulatory | Intended function, exclusions, market assessment and acceptance measures. |
| System and interface design | Systems and software engineering | Architecture, interface contract, failure states and compatibility policy. |
| Physical implementation and transfer | Electronics, mechanical and manufacturing | Power/RF/EMC evidence, provisioning and production tests. |
| Risk, security, privacy and usability | Named discipline owners with quality oversight | Linked assessments, controls and verification/validation plans. |
| Integration and release evidence | Verification, validation and quality | Supported-system test results, anomalies and release decision. |
| Deployment and lifetime support | Service, operations and security | Installation, monitoring, incident, patch and retirement procedures. |
On smaller screens, scroll the table sideways to view all columns.
Estimate one-off development and test effort separately from recurring hosting, connectivity subscriptions, monitoring, certificate management, support, security maintenance and compatibility testing. Include specialist laboratories, hospital IT access and partner test systems as dependencies. A universal percentage uplift is not credible: scope and assurance needs drive the work.
Planning workshop · 20 minutes
For the record-export variant, create one page with the benefit, architecture boundary, three failure requirements, five evidence items, accountable owners and recurring support costs. List the assumptions that could change the estimate.
Done criterion: a colleague can explain what is connected, what remains local, how failure and recovery behave, who supplies the evidence and who supports the system after release. Every open assumption has an owner. Only then compare the benefit with the full commitment.
Continue learning and check primary guidance
- MTL-140 — Start here: developing a medical device
- MTL-111 — Data, connectivity and interoperability
- MTL-116 — Verification and validation
- FDA — Interoperable medical devices (2017)
- FDA — Radio frequency wireless technology in medical devices (2013)
- FDA — Cybersecurity in medical devices (February 2026)
The FDA references provide primary starting points for interoperability, wireless and cybersecurity considerations; they are not a complete global compliance checklist. Determine applicable legislation, standards, editions and evidence for the actual device and markets. This fictional example is for learning, not a release-ready pump specification.