Most connected monitoring pilots fail for reasons that have nothing to do with the device. They were run without a written question, so nobody could say afterwards what had been learned; or without an owner on every hop in the data path, so a gap appeared in the middle of the chain and no one could locate it; or with success measured in language borrowed from clinical studies, so the pilot was judged against evidence it could never produce.
This guide is written for the person who has to defend the roll-out decision afterwards. It is deliberately narrow: it covers scope, device count, the data flow, authorization, success criteria and the limits of what a pilot can prove. The stages beyond the pilot — the scale decision and operational ownership at volume — are set out on the integration-requirements path, so we do not repeat them here.
1. Define the Written Question First
A pilot is an experiment with an operational budget, and it is only an experiment if it has a question. Write it down before anything is ordered, and write it in a form that could be answered with a no. A pilot whose question can only be answered yes is a demonstration, and a demonstration is not evidence for a roll-out decision.
Three questions are usually the real ones: does the workflow complete end to end at all; does data arrive where it will actually be read; and can the organisation support this at its current size without extraordinary effort. Each one is answerable from operational observation. None of them requires the organisation to make a clinical claim, which matters because no such claim is available to make.
2. Size the Fleet From Your Capacity, Not From a Published Figure
This is the question buyers ask first, and it is the one this page will not answer with a number. No verified figure exists — not a participant count, not a device count, not a duration — and publishing an estimate in a table would make it indistinguishable from a fact by the time it reached a procurement document. What follows instead are the variables your number depends on.
Onboarding capacity
A device that cannot be onboarded is a device that will not be used. The count is bounded by how many participants your team can enrol and train in the pilot window, not by budget.
Sites and sessions
Each additional site multiplies the setup and training effort, and sites differ in how much support they need to run the same protocol.
Replacement and spare policy
Every fleet needs a replacement path. If the policy is unknown, the effective fleet size is unknown too — obtain it in writing before fixing a total.
Wear duration per device
How long a device stays in service determines how many are simultaneously in the field for a given number of participants.
Pooled or participant-assigned
Pooled devices are re-provisioned between users; assigned devices are not. The choice changes both the count and the support model.
Hops that must be exercised
The count has to be large enough to exercise every hop in the data flow at least once, including the low-frequency ones. This is a floor, not a target.
Device count Not confirmed
This guide publishes no device count, participant count, pilot duration or benchmark, because none is verified. Derive the count from the onboarding capacity you can actually staff, hold a documented replacement policy for the fleet, and treat the minimum number needed to exercise every data hop as a floor rather than a target. If a supplier offers you a "typical" pilot size, ask what it is derived from — and get the replacement terms in writing before you commit to a total.
3. Map the Six Data Hops and Name an Owner for Each
The data path is the part of a pilot that most reliably produces surprises, and it produces them because nobody wrote down who owns the middle. Draw the chain, then put a name and a failure symptom against every hop. If a hop has no owner, the pilot plan has a defect — and it is cheaper to find it on this page than during a live deployment.
The device
Owner: The participant holds it; the organisation owns the device fleet and its replacement policy.
Failure symptom: A scheduled measurement session simply does not appear. No reading exists, so nothing downstream can be missing — which is why this failure is often invisible until data completeness is counted.
The transfer path
Owner: Whoever operates the device-to-app or device-to-cloud path — named before the pilot, not after the first gap.
Failure symptom: The session was taken on the device but never leaves it. This is the hop most often assumed rather than owned.
The application or cloud layer
Owner: The party operating the intermediate layer that holds the reading before it reaches your system.
Failure symptom: Readings exist in the intermediate layer and never appear in the receiving platform. Retention and hosting questions live at this hop, which is why they belong on the open-item list.
The receiving platform
Owner: You. This is the system your organisation operates and is accountable for.
Failure symptom: Data arrives in a form, volume or cadence the platform was not built to accept — an integration failure that surfaces as an operational one.
The review point
Owner: The role that is scheduled to look at readings, and the queue they look at them in.
Failure symptom: Readings arrive correctly and nobody sees them. This is the hop that converts a monitoring service back into a data-collection exercise.
The person who acts
Owner: The named human decision point, with the escalation route recorded rather than assumed.
Failure symptom: A reading that needed a decision produced no decision. Everything upstream can work and the workflow still fails here.
Interface specifics that you cannot confirm yet — what data can move, over what mechanism, hosted where — belong on the open-item list rather than in the design. A pilot that assumes an integration exists is testing an assumption, not a workflow.
4. Settle the Authorization Questions, Including Withdrawal
Authorization is the condition the whole workflow runs on. It is not a formality attached to the end of onboarding, and it is not a legal question that can be deferred while the operational design proceeds — the operational design depends on it.
| Question | What Has to Be Established |
|---|---|
| What data leaves the device? | Name the measurement and everything travelling with it — timestamps, session identifiers, any device telemetry. A system that shares more than it declared is a system whose authorization does not describe it. |
| Who may see it? | Name the roles rather than the systems: the participant, the reviewing clinician, the care team, and anyone downstream. Access that was never granted explicitly is access that cannot be defended. |
| On what documented basis? | The basis has to exist as a record you can produce, not as an understanding. This is the question that turns data sharing from a convenience into a position your organisation can hold. |
| How is withdrawal handled after the fact? | Withdrawal has to be exercisable and to have a defined effect on data already collected. Test it during the pilot rather than documenting it — an untested withdrawal path is untested precisely where it matters. |
Why this is written as a condition rather than a formality
In the one implementation this company reports, the family-doctor service point launched at the Longcheng China Telecom business hall combines family-doctor enrollment, a health-service package and a LUROGEF blood-pressure watch, and watch data can be shared with the Longgang family-doctor platform only with the resident's authorization. That sentence is the whole design in miniature: the data path exists, and its operation is conditional on a record held by someone else. A pilot should exercise that condition — including a withdrawal — rather than assume it.
Reported by the company; not an independently verified deployment record. What applies in your jurisdiction is a question for your own advisers, and this page names the questions rather than asserting a rule.
5. Agree Success Criteria That Are Not Clinical-Outcome Claims
This is where connected monitoring pilots most often go wrong, and the failure is one of language rather than of measurement. A pilot can tell you whether a workflow runs. It cannot tell you whether a health outcome improved — that requires a study design nobody is running, and our products carry no clinical-evidence basis to build one on. Borrowing clinical framing therefore does two damaging things at once: it sets the pilot up to be judged against evidence it cannot produce, and it puts a claim into your organisation's material that nobody can support.
| Success Criterion | What It Tells You | Target Value |
|---|---|---|
| Provisioning completion | Whether the device can actually be brought into service at the pace your onboarding model assumes. | — set from your own onboarding capacity; no verified benchmark exists. |
| Participant onboarding completion | Whether the training and consent steps are achievable with the people you will actually serve, not with an idealised cohort. | — depends on your service model, not on a published figure. |
| Measurement-session completion | Whether scheduled sessions happen in practice, which is a protocol and training question rather than a device question. | — measured within the pilot, not imported from outside. |
| Transfer reliability over the pilot window | Whether readings that exist on the device actually arrive. This is the only hop-level measure that catches the silent failures in the middle of the chain. | — observed during the pilot; no uptime or reliability figure is published for any product. |
| Data completeness at the receiving end | Whether what arrived is usable by the review point — the difference between data being present and data being actionable. | — set against the review workflow you operate. |
| Support-request volume | What your real support load is per participant, which is the number the scale decision actually turns on. | — this is the figure the pilot exists to discover. |
Two rules make this set work. First, measure the hop-level behaviour rather than only the end result: a workflow that completes for the wrong reason will fail later, and transfer reliability is the measure that catches it. Second, measure the support load honestly, including the requests you resolved informally — because that number, not the device count, is what the scale decision turns on.
6. State What the Pilot Cannot Prove
Put this list in the pilot report itself, next to the results. It is not a disclaimer — it is what stops a well-run pilot from being over-read by the people who funded it.
What a Pilot Cannot Establish
- Clinical effectiveness of the device or the service around it.
- Diagnostic performance of any kind.
- Accuracy validation for the watch and ring families — no accuracy or clinical validation record is held for any of them, and none is claimed. The S10 CGM system is the exception: its MARD figure is published, and a pilot is still not what establishes it.
- Any population-level conclusion, because a pilot is not a study.
- Regulatory or market access in any jurisdiction.
- Cost-effectiveness, which depends on a service model that does not exist yet.
What It Can Establish
- That the operational chain completes end to end at the scale you can actually staff.
- That readings arrive where they will be read, in a form the review point can use.
- That the authorization step is workable — including the withdrawal path, once you have run it.
- What your real support load is per participant, before you commit to a larger number.
Those four are what a scale decision actually needs. The six on the left require evidence a pilot cannot generate, at any size.
7. The Pilot's Exit Condition
The stages that follow a pilot — review against these criteria, the scale decision, and operational ownership at volume — are set out in the pilot-to-scale stages on the hub, and we do not repeat them here. What belongs here is the pilot's own exit condition, because it is the hand-off point between the two:
- The written question from section 1 has been answered, in a form that could have come out no.
- Every one of the six hops has a named owner and an observed failure symptom — not an assumed one.
- The authorization step has been exercised at least once, including a withdrawal.
- The support load is a measured number rather than an estimate.
If any of those four is missing, the scale decision is being made on incomplete information — and the cost of completing the pilot properly is almost always smaller than the cost of scaling on a guess. If the device selection itself is still open, start with how to select a measurement device for a remote monitoring workflow; a pilot cannot be planned against a device that has not been chosen against a written intended use.