Case study

Making home CTG monitoring workable for patients, clinicians, and the data behind it

A proof of concept that turned a home CTG monitoring concept into a coherent patient, clinician, and data workflow that could be evaluated before committing to full-scale development.

  • Medtech
  • Product Discovery & Validation
  • Home monitoring workflows
  • Proof of Concept
  • Discovery
  • Feasibility analysis
  • Workflow design
  • PoC delivery
Client / Initiative
NDA
Industry / Domain
Medtech
LLI Role
Product Discovery & Validation, with product and engineering delivery of the PoC
Scope
Proof of Concept (PoC)

The problem

Home CTG monitoring was intended to move a clinically sensitive measurement out of the clinic and into the patient's home, supported by third-party monitoring hardware. In practice, the workflow around that measurement was fragmented, and it was unclear whether patients could complete a usable session or whether clinicians could act on the result.

  • Home CTG workflows were fragmented across devices, patients, and clinical teams
  • Device connectivity was unreliable or unclear to the patient
  • Patients had insufficient guidance during a clinically sensitive measurement
  • It was uncertain whether a result had been delivered or reviewed
  • Sessions produced noisy or unusable data
  • Clinical context around a measurement was scattered rather than consolidated
  • Clinician triage was inefficient, with attention spread across low-value information
  • Auditability and data-flow behaviour were not clearly defined

Left unresolved, these issues would undermine both the clinical usefulness of home monitoring and the operational case for running it at scale.

Our approach

We approached the engagement as a discovery and feasibility study, using the PoC to validate the most critical assumptions rather than treating it as a build request.

That meant deciding what deliberately stayed out of scope before deciding what to build.

Key decisions

  1. 01

    Prioritise CTG as the most clinically sensitive workflow

    Rather than attempting to cover the complete device ecosystem.

  2. 02

    Design around patient guidance and reduced uncertainty

    The home measurement had to be completable without a clinician present.

  3. 03

    Make clinically important information visible quickly

    So clinicians could prioritise attention instead of interpreting raw context.

  4. 04

    Treat data integrity as part of the workflow

    Failed sessions, delivery status, and auditability were designed in, not deferred.

  5. 05

    Keep the PoC focused on validating feasibility, workflows, and value

    Without engineering complexity the stage did not justify.

The objective was a concept concrete enough to evaluate, not a product presented as finished.

The solution

The PoC covered the patient measurement journey, the clinical review workflow, and the platform foundations connecting them.

Patient experience

  • Guided CTG preparation and measurement
  • Device connection, with recovery from connectivity issues
  • Feedback during and after a measurement
  • Simplified status and severity information
  • Confirmation that a result had been shared and reviewed
  • Recent measurements and basic guidance

Clinical experience

  • Alert-first prioritisation of patients
  • A centralised view of CTG, vitals, alerts, and supporting context
  • Acknowledgement and escalation workflows
  • An audit timeline of what happened to a measurement
  • Lightweight workload information supporting triage

Platform foundations

  • Integration with third-party CTG hardware platforms
  • Secure, non-destructive data storage
  • Architecture designed with NHS-controlled environments and future data-governance requirements in mind

The PoC was built to be evaluated. It was not clinically validated, certified, or deployed in a live care setting.

Technology stack

  • Frontend

    Responsive web (mobile and desktop)

    Separate patient and clinician experiences over shared data.

  • Backend

    Services for ingestion, storage, and auditability

    Secure handling of measurement data and its delivery status.

  • Architecture

    Prepared for healthcare data governance

    Structured so future governance requirements could be met without redesign.

Why these technologies? At PoC stage the architecture prioritised speed of validation, clarity, maintainability, and secure data handling, while remaining straightforward to evolve if the concept progressed.

Dedicated team

  • Product-focused software engineers

    With healthcare workflow experience.

  • UX designer

    Focused on clinical clarity and the patient experience.

  • Technical lead

    Responsible for data integrity, integration, and delivery coherence.

Engineering standards

For a PoC in a clinical context, credibility comes from how the data and the workflow behave rather than from feature count.

  • Data integrity treated as a product requirement
  • Explicit handling of failed or incomplete data flows
  • Auditability of what was measured, delivered, and reviewed
  • Coherent patient and clinician workflows rather than isolated screens
  • Maintainable foundations for further development
  • No unnecessary complexity at PoC stage

Results and impact

For patients

  • Clearer guidance through a clinically sensitive measurement at home
  • Visibility of measurement, delivery, and review status
  • Less uncertainty about whether a session had worked

For clinicians

  • Faster prioritisation through alert-first review
  • Clearer acknowledgement and escalation paths
  • Less time spent interpreting fragmented or low-value information

For the organisation

  • A more concrete and validated concept for home CTG monitoring
  • A shared product and technical direction
  • Clearer understanding of important workflows, data requirements, and risks
  • Foundations for deciding how the product could progress beyond the PoC

These are the objectives the PoC was designed against and what it made possible to assess, not measured production outcomes.

Why this case matters

Healthcare product development requires more than building features. Product decisions, clinical workflows, patient understanding, data quality, technical feasibility, and auditability have to be considered together from the beginning, because a weakness in any one of them makes the others unusable.

This is what Product Discovery & Validation is for: the important assumptions were made concrete through an actual PoC, with constraints and trade-offs visible before committing to a larger-scale product.

It also reflects how LLI works. We took responsibility for both the product thinking and the engineering, rather than delivering isolated screens or individual features.

  • The PoC turned a complex home-monitoring concept into a coherent patient, clinician, and data workflow that could be evaluated before committing to full-scale development.

More case studies

View all

Start the conversation

Build the right technology with the right engineering partner.

Tell us what you are planning, and our senior team will help you define the strongest way forward.

Talk to our team