How to use this case study
This example treats the app, cloud and operational service as one product. Follow a safety-significant data item across components and organisations, then ask whether responsibility, evidence and change control remain intact.
Case at a glance
A patient app receives measurements from a compatible home-use device, presents trends and sends encrypted records to a hosted service. A clinician portal displays prioritised review queues. The software supports monitoring but does not diagnose automatically or replace urgent-care instructions.
Patient value
Reliable access to measurements, trends and actionable status information.
Clinical value
A controlled longitudinal view that helps professionals prioritise review.
Technical boundary
Mobile apps, APIs, hosted services, databases, clinician portal and operational tooling.
Principal uncertainty
Whether data remain timely, attributable and correctly interpreted across intermittent connectivity.
Separate monitoring support from diagnosis
The system is intended to collect measurements from specified compatible devices, display longitudinal information to adult patients and authorised healthcare professionals, and support prioritisation against predefined review criteria. It does not provide an autonomous diagnosis or emergency response.
The boundary constrains notifications, claims, timing expectations and clinical evaluation. Product wording must not imply that absence of an alert means absence of risk. Use MTL-102 — Intended Purpose, Users and Use Environments.
Make distributed responsibility explicit
Define the meaning of data at every boundary
- Every measurement shall retain source-device identity, patient association, unit, original timestamp and synchronisation state.
- The app shall distinguish measured, manually entered, calculated and corrected values.
- Retry and recovery shall not create duplicate records or hide missing intervals.
- Clock uncertainty and offline acquisition shall be visible where clinically relevant.
- Priority rules shall use controlled versions and preserve the inputs and output of each evaluation.
- Notifications shall state their meaning, delivery limitations and required user action.
- Deletion and retention shall respect safety, regulatory, privacy and contractual obligations.
Apply MTL-111 — Data, Connectivity and Interoperability to the semantic as well as technical interface.
Combine safety, security and privacy decisions
Missing measurement
Connectivity failure creates false reassurance. Show data freshness, missing intervals and degraded operation.
Wrong patient
A valid value reaches the wrong record. Control enrolment, pairing, identity and reconciliation.
Altered priority
Rule or configuration error changes clinical review order. Version, test, authorise and monitor every rule.
Account compromise
An attacker views or alters sensitive records. Use proportionate authentication, authorisation, detection and recovery.
Safety and cybersecurity share system assets and consequences but require explicit linkage. See MTL-109 — Medical-device Cybersecurity and MTL-112 — Privacy and Data Protection by Design.
Design for degraded service
The mobile app retains recent records and clearly identifies unsynchronised data. The API is idempotent, rejects invalid schemas and preserves provenance. Clinical prioritisation runs as a versioned service whose output can be reconstructed. No single notification channel is treated as guaranteed delivery, and immediate safety instructions remain available without cloud access.
Trust boundaries, supported versions and recovery behaviour belong in the architecture, following MTL-105 — Systems Engineering, Architecture and Interfaces.
Test the service as users experience it
Mobile behaviour
Pairing, permissions, offline use, accessibility, OS combinations, updates and recovery.
Interface integrity
Schema, identity, ordering, duplication, latency, errors, rate limits and compatibility.
Service assurance
Infrastructure configuration, resilience, backup, restore, observability, access and deployment controls.
Claim validation
Representative data, priority performance, user interpretation, workflow fit and known limitations.
Operational controls are product controls
Release approval covers source, build artefacts, infrastructure configuration, database migration, feature flags, rollback, monitoring and support readiness. Alerts distinguish service health from product-performance signals. Incidents enter both technical response and medical-device assessment. Apply MTL-227 — Cloud, Platform and DevOps Engineers.
Follow one measurement thread
Use an operating-system change to test lifecycle control
A mobile OS release restricts background communication, delaying synchronisation for some patients. The team must determine affected versions and workflows, test foreground and background states, monitor real-world latency, communicate limitations, update support rules and assess whether clinical claims or regulatory obligations are affected.
The event is a product change crossing software, usability, risk, supplier dependence, clinical performance and post-market surveillance—not simply an app defect.
Questions to challenge the case
- Which functions remain useful and safe without cloud connectivity?
- How does a reviewer know that data are complete and current?
- Who approves infrastructure and priority-rule changes?
- Which third-party service failure has the greatest product consequence?
- Can every displayed value be reconstructed from its source and configuration?
- What operational signal should enter post-market surveillance?