MyTwin
Back to the blog
Clinicians5 min read

Remote patient monitoring: building a care pathway that works

Remote monitoring does not improve a care pathway simply by collecting data. Its value depends on a precise indication, interpretable alerts, a team able to respond and continuous evaluation. This framework helps care teams move from yet another dashboard to a genuine care protocol.

By Rubens Valcy

Founder of MyTwin

Published on

Contents
  1. Remote monitoring or medical telemonitoring?
  2. Defining the clinical scope
  3. Designing a complete alert chain
  4. Building monitoring into the clinical workflow
  5. Informing and supporting patients
  6. Protecting data and managing vendors
  7. Evaluating before and after deployment
  8. Frequently asked questions
  9. Sources

A hospital or practice can easily measure more: weight, blood pressure, heart rate, reported symptoms, treatment adherence or activity. The decisive question is a different one: which decision will change when the data changes? That principle, starting from the decision rather than the sensor, is covered in our article on real-world data.

This guide covers the next step: turning remote monitoring into a care protocol, with a defined clinical scope, an alert chain, an accountable team and an evaluation plan.

Remote monitoring or medical telemonitoring?

“Remote patient monitoring” is a broad term, and not every country draws its boundaries in the same place. France offers a precise example. There, medical telemonitoring (télésurveillance médicale) has a regulatory definition: a medical professional remotely interprets the data needed for follow-up and, where appropriate, takes decisions about the patient’s care. As France’s National Authority for Health (HAS) reported, two decrees have integrated it into the country’s standard healthcare framework.

A messaging tool, a satisfaction survey or a consumer wearable does not become medical telemonitoring simply because it is built into an app.

Before deployment, document the indication, the population, the expected data, the possible decisions and the person responsible. If no action is tied to a signal, collecting it should be questioned.

Defining the clinical scope

Who is the program for?

Inclusion and exclusion criteria must be explicit. They may cover the condition, its stage, clinical stability, the ability to use the device, the availability of a caregiver or access to a backup care team. A program designed for heart failure cannot be transferred as-is to mental health or post-operative follow-up.

In France, HAS publishes reference frameworks for specific telemonitoring activities. They describe the functions, organization and conditions specific to each indication. Their existence is a reminder that a one-size-fits-all alert model is rarely defensible. Covered activities are also entered on a dedicated list, and HAS details the process in a guide for applicants.

Which outcome are you trying to improve?

Choose a small number of goals: detecting deterioration earlier, securing a care transition, avoiding an unnecessary visit, improving adherence to an agreed plan or collecting symptoms between appointments. Pair each goal with a clinical indicator and an organizational one.

A high login rate can signal good adoption, not better health. Conversely, fewer alerts is only good news if it does not hide dropouts or missing data.

Designing a complete alert chain

An alert is only useful if it reaches the right team, at the right time, with enough context to act. The protocol must specify every link in the chain, from the trigger to the instructions given to the patient in an emergency.

  1. Trigger

    The data point or combination of data that triggers the signal

  2. Priority

    The priority level

  3. Review time

    The maximum time before review

  4. Owner

    The role that receives and qualifies the alert

  5. Action

    The possible actions and how they are documented

  • After hours

    The out-of-hours procedure

  • Emergency

    The instructions given to the patient in an emergency

Fixed thresholds are simple but can generate too many false positives. Personalized thresholds can be more relevant, provided they are justified and audited.

Testing thresholds before scaling up

To keep alert fatigue from setting in, track the number of alerts per patient and per professional, the share reviewed on time, the actions triggered and the alerts judged irrelevant in hindsight.

Plan a pilot phase. Analyze errors, duplicates and periods of overload. Adjust thresholds through a documented process rather than letting each user invent their own rules.

Building monitoring into the clinical workflow

Remote monitoring often fails when it creates a parallel channel: a new password, a standalone screen, data that never makes it into the medical record and unclear responsibilities. Map the real pathway, from the moment data comes in to the decision and the clinical note.

MyTwin for clinicians builds that continuity between consultation and follow-up: a digital twin that monitors patients continuously between visits, alerts physicians only when necessary and helps every patient stay on their care pathway. MyTwin makes recommendations to the professional, who stays in control of the activated modules.

Whatever solution you consider, ask how the data integrates with existing systems, how the team documents an action and how a patient can report a problem the algorithm missed.

Informing and supporting patients

Enrollment depends on clear information: goals, data collected, how often it is reviewed, the limits of the service and what to do in an emergency. Digital skills, access to a device and language must be checked. An alternative should be offered when the program creates a barrier.

Patient education and support should not be reduced to a technical tutorial. Patients need to understand what they are measuring, what counts as a relevant signal and why missing data can limit interpretation.

Protecting data and managing vendors

Health data requires precise governance. Identify the data controller, processors, purposes, retention periods, access rights and any data flows leaving the organization. Check the hosting and security requirements that apply in your context. In France, for example, the data protection authority (CNIL) sets out the formalities for processing health data.

Compliance is more than a clause in a contract. Test access rights, revocation, logging, incident management and reversibility. Also document the version of the software or model in use whenever it can change the results.

Evaluating before and after deployment

A balanced dashboard can track:

  • coverage of the eligible population;
  • equity of access and reasons for refusal;
  • data completeness and quality;
  • review and response times;
  • the workload created;
  • adverse events and missed signals;
  • the experience of patients and professionals;
  • clinical outcomes defined in advance.

Compare results with a baseline and interpret changes with caution. A drop in hospitalizations observed without a comparison group may stem from other changes to the care pathway. If the goal is to demonstrate effectiveness, a suitable evaluation protocol is required.

Frequently asked questions

Sources

  1. Haute Autorité de santé (HAS), January 26, 2022, “Télésurveillance médicale : référentiels des fonctions et organisations des soins”.
  2. Haute Autorité de santé (HAS), January 13, 2023, “Télésurveillance médicale : deux décrets actent l’intégration dans le droit commun”.
  3. Haute Autorité de santé (HAS), March 30, 2026, “Liste des activités de télésurveillance médicale : guide pour le dépôt de dossier”.
  4. CNIL, May 22, 2024, “Quelles formalités pour les traitements de données de santé ?”.

This article is provided for information purposes only. It does not replace advice, diagnosis or treatment from a healthcare professional.