How to use this case study
This is a deliberately simplified, fictional composite. Follow one decision across functions and ask whether the evidence remains coherent. The purpose is to expose interfaces and trade-offs—not to suggest that every connected injection product should use the same architecture or controls.
Case at a glance
A reusable electronic module attaches to a compatible pre-filled injector. It detects selected injection events, gives local status feedback and sends an event record to a patient mobile application. The app presents guidance and history, then synchronises permitted information to a hosted service for review by an authorised healthcare professional.
Patient value
Clear feedback and an accessible history of recorded injection events.
Business boundary
The system supports administration; it does not select the medicine or prescribe a dose.
Technical boundary
Accessory, embedded software, mobile app, cloud service and supported interfaces.
Principal uncertainty
Whether sensor observations reliably represent the clinically meaningful injection state.
Start with a controlled intended purpose
The system is intended to assist adults who self-administer a prescribed medicinal product using a specified compatible injector by providing step guidance, recording detected injection events and making those records available to the patient and authorised healthcare professionals. It does not control delivery, determine dose or confirm that the prescribed dose entered the body.
The final sentence prevents a sensor-derived event from being mistaken for dose-delivery confirmation. The limitation drives labelling, user-interface language, clinical claims and acceptance criteria. See MTL-102 — Intended Purpose, Users and Use Environments.
Draw the system boundary before allocating work
Ownership can be distributed, but accountability cannot disappear between suppliers. Apply MTL-105 — Systems Engineering, Architecture and Interfaces to define the interfaces and assumptions.
Translate the use scenario into verifiable requirements
- The accessory shall identify only supported injector configurations or indicate incompatibility.
- The system shall distinguish a detected injection event from a confirmed delivered dose.
- The app shall retain an attributable local event record during loss of connectivity.
- Restored synchronisation shall prevent duplicate or incorrectly ordered records.
- Safety-significant feedback shall remain available without dependence on the cloud service.
- Only authorised users shall access identifiable event history.
- Every displayed record shall identify its source, time basis and synchronisation state.
Each requirement needs a source, acceptance criteria, allocation, risk relationship and verification method. See MTL-103 — User Needs and Design Inputs.
Risk analysis changes the product design
False completion indication
A patient believes administration completed when the event evidence is incomplete. Control through sensing logic, qualified wording, visible uncertainty and representative validation.
Missing or duplicate record
History may mislead a patient or professional. Control identity, time, retransmission, deduplication and synchronisation states.
Wrong patient association
An accurate event is attached to the wrong account. Control pairing, identity, authorisation and visible account context.
Unavailable service
Network or cloud failure interrupts a dependent workflow. Keep immediate guidance local and define degraded behaviour.
The team must trace controls into requirements and verify the complete control implementation. Use MTL-114 — Medical-device Risk Management.
Architecture makes the safety argument implementable
The accessory owns time-critical event sensing and local feedback. The app owns guided interaction and the patient-facing record. The hosted service owns controlled synchronisation, longitudinal storage and professional access. A loss of cloud service therefore does not remove immediate injection guidance, while delayed records remain visibly unsynchronised.
Architecture records must also define trust boundaries, update authority, supported combinations, data meaning, time synchronisation and safe recovery. Cybersecurity controls use MTL-109 — Medical-device Cybersecurity; interoperability decisions use MTL-111 — Data, Connectivity and Interoperability.
Build an evidence programme around claims and risk
Sensor and injector evidence
Representative injector variants, attachment states, environmental conditions, use rates, battery states and foreseeable handling.
Software and interface verification
Algorithms, state transitions, data integrity, timing, error handling, platform combinations, updates and recovery.
Usability evidence
Pairing, attachment, interpretation of feedback, offline states, record uncertainty and recovery by representative users.
Clinical evidence
Support the precise claims made for guidance and event recording without implying unproven dose confirmation or improved outcome.
Follow one thread through the evidence
A reviewer should be able to move in both directions through this chain and reach the exact released configurations used for the evidence.
Design transfer covers the whole delivery system
Transfer includes production tests and assembly for the accessory, signed mobile and embedded builds, cloud infrastructure configuration, supported-version rules, installation and account provisioning, release notes, service diagnostics, support training and post-market data capture. Supplier agreements define notification and evidence for changes to critical components and services.
Use a lifecycle change to test the control model
A phone-platform update changes Bluetooth background behaviour and increases delayed synchronisation. The team must assess whether immediate feedback remains correct, whether record timing could mislead users, which supported combinations are affected, and whether app, labelling, monitoring or customer communication must change.
The impact analysis crosses software, usability, risk, cybersecurity, clinical claims, regulatory assessment and post-market surveillance. Treating it as an isolated compatibility defect would miss the product-level consequences. See MTL-129 — Configuration and Change Management.
Questions to challenge the case
- Is the intended purpose narrow enough to support credibly?
- Where could users infer more than the sensor actually establishes?
- Which functions must remain available without a phone, network or cloud service?
- What is the minimum evidence needed before adding a new injector variant?
- Which supplier or platform change could invalidate the safety argument?
- What field data would reveal that the assumptions were wrong?