Buyer Guide
How to Evaluate a CGM System for Remote Monitoring Programs
A continuous glucose monitoring system is not one device, and that single fact reshapes how a partner should evaluate one. The sensing element is a separate adhesive sensor worn on the upper arm; the watch and the app present what it obtained. Once the architecture is clear, the evaluation stops being a feature comparison and becomes a set of verifiable questions — about the boundary, the data workflow, the ownership of each hop, and the documents that have to exist before a programme launches.
1. Write the programme promise down before you compare any hardware
The most useful first artefact in a CGM programme is not a specification comparison. It is a single paragraph stating what the programme will tell the wearer, what the brand will say publicly, and what the programme will deliberately not claim. That paragraph is the evaluation's requirements document, and it does something a feature list cannot: it fixes the boundary before commercial pressure starts pushing against it.
The reason to start here is structural. In a two-part system the sensing element is a worn consumable and the display layer is consumer electronics, so the promise the wearer experiences is assembled from both. A promise written after the hardware is chosen tends to inherit the hardware's marketing language, and that language is usually the least defensible part of the package.
Write down four things: what the wearer is told the system does; what the brand says publicly; what the programme will not say; and which of those statements depends on documentation you do not yet hold. The fourth item is the one that saves the most money later.
2. Compare on architecture, not on feature lists
Feature lists in this category converge because they are written to. Every supplier describes continuous monitoring, app presentation and a comfortable wearable, because those are the category's entry conditions. Architecture does not converge: the number of physical parts, which part senses, which part displays, and what the wearer sees when the link or the display device is unavailable are all structural facts that differ between systems and cannot be produced by copywriting.
| Common Feature-list comparison | Recommended Architecture review | |
|---|---|---|
| What is being compared | Bullet points on a supplier page | The physical parts and which one senses, transmits and displays |
| Convergence risk | High — competitors write bullet lists to look identical | Low — part counts and roles are hard to imitate |
| Catches the watch-sensing overclaim | ✗ | ✓ |
| Survives a marketing-copy review | Often fails when a display device is described as sensing | Passes — the claim boundary is derived from the architecture |
| Reveals the failure surface | Hidden until launch | Named per part before launch |
| Feeds the integration plan | No — features do not map to hops | Yes — each part maps to a workflow hop and an owner |
The physical reason architecture review has to come first is that the measurement target is not reachable from a wrist. Our sensor-to-display explainer sets out that constraint, the sensing principle behind it, and why the displayed value is a representation rather than the raw measurement.
3. Verify the sensor-versus-display boundary in the supplier's own copy
This is the highest-value hour you will spend in the whole evaluation, and it costs nothing. Take the supplier's product page, packaging, app store listing and any paid creative, and mark every sentence in which a display device — a watch, a ring, an app, a phone — is written as if it obtains a glucose measurement.
In an architecture of this class, the sensing element is the separate adhesive sensor applied to the upper arm. The watch and the app receive synchronized data and present it. A supplier whose own material blurs that line has told you two things: that their claims were not reviewed against their architecture, and that you will inherit the resulting overclaim the moment you reuse their language.
Two sentences are always wrong for this product class. The first describes a watch or a ring as measuring glucose. The second describes the measurement as non-invasive. What we have for this system depicts an adhesive sensor applied to the arm, and no substantiated non-invasive claim exists behind it — so neither sentence is publishable, regardless of how the source material phrases it.
4. Map the data workflow and give every hop an owner
A remote monitoring programme fails at handovers far more often than at components. The workflow below is the integration blueprint: six hops, each with a question that has to be answered in writing before the programme launches, because a hop without a named owner is an incident waiting for a date.
| Workflow hop | What happens | The ownership question to settle in writing |
|---|---|---|
| Acquisition | The single-use adhesive sensor on the upper arm obtains the measurement. It is the only part of the system that senses anything. | Who supplies the sensor consumable, on what replenishment terms, and who is accountable if a sensor does not perform as described? |
| Wireless transfer | The reading leaves the sensor and is carried to a paired display device or the companion application. Link-specific parameters are not published for this system. | What happens during an interruption, how long a gap the platform tolerates, and who is notified when a gap exceeds it? |
| Display device | A compatible LUROGEF smartwatch presents synchronized values. It is a display endpoint and adds no measurement of its own. | Which device models and firmware versions are actually tested with this system, and who validates a new model before it is added? |
| Companion application | The smartphone application receives and presents the synchronized data stream, and is the primary interface for the wearer. | Who publishes the app in each store — supplier or brand — who owns the store listing, and who answers end-user support? |
| Beyond the application | Export format, hosting, third-party platform integration and long-term retention. None of this is confirmed for this system. | What export format exists, over what interface, at what cadence, under what licence, and who is the data controller for the end user? |
| Programme support | The operational layer: onboarding, wearer instructions, replacement logistics and escalation when a reading looks unusual. | Who handles a wearer question, within what hours, in which language, and what is the defined escalation route? |
Two of these hops deserve emphasis. The last hop — everything beyond the companion app — is where this system's evidence currently stops: export format, hosting, third-party integration and retention are not yet confirmed. Treat that as a set of questions with an expected answer shape, not as a capability to be assumed. And the support hop is a cost line, not an afterthought: a worn consumable generates replacement and wear questions for the whole life of the programme. The system overview page carries the full list of what is documented and what is still pending.
5. Verify compatibility per programme rather than inferring it
Compatibility is the quietest failure mode in a connected-monitoring programme, because it degrades over time instead of breaking at launch. A display device that worked at integration can stop working after an operating system update; an app version that presented correctly can change its background behaviour without any change on the sensor side.
Ask for the tested matrix — device models, firmware versions, phone operating system versions and app versions — and ask who validates a new model before it is added. If the matrix is not available in writing, treat compatibility as unverified for the programme rather than inferring it from a photograph of a working pair. This system's verified compatibility list has not been supplied, and the system overview states that openly rather than filling the gap.
6. Assemble the documentation set, and know who owes what
Continuous glucose monitoring systems are regulated as medical devices in most markets, and registration is both territory- and model-specific. That produces a division of labour a partner should plan around: the supplier owns the product documentation, and the importer or local entity typically carries the registration and post-market obligations in the territory.
We do not assert what any particular market requires, and we do not treat any market’s requirements as satisfied. What it does say is that the documentation request should start at the same time as the commercial discussion, not after it, because registration timelines are set by the market rather than by the supplier's schedule.
- The system specification, with each value marked as verified or still a claim.
- The verified display-device, firmware, app and operating-system compatibility matrix.
- The shipping configuration in writing, including every accessory, rather than inferred from packaging imagery.
- For each registration number you intend to reference: the holder, covered product or model, scope, validity and intended use.
- The validation documentation behind any performance figure the brand intends to publish — or a clear decision to publish none.
- The interface and licence terms for any data export, plus who is the data controller for the wearer.
7. Plan for the failure modes that appear after launch
The failure modes below are not defects in a specific product; they are the recurring operational patterns of connected monitoring programmes built on a worn sensor plus a display layer. Each is cheap to design for beforehand and expensive to improvise afterwards.
The transfer layer
-
Readings disappear from the app or the watch for hours at a time.
A transfer interruption, a display device out of range, or a background-permission change on the phone after an operating-system update.
- Treat transfer continuity as a monitored platform property with a defined gap threshold, and define what the display shows during a gap — a gap, never an interpolated value.
- Re-verify the compatibility matrix after every phone or watch operating-system release.
The wear layer
-
Wearers stop wearing the sensor within the first days of a programme.
Adhesion or application-site discomfort, or instructions that never explained what the wear period involves. The sensing element is a worn consumable, so adherence is a product-design variable rather than a user failing.
- Invest in application instructions and site guidance, and measure wear-period completion as a programme metric from day one instead of reconstructing it from complaints.
- Read how the architecture bounds wear behaviour in the sensor-to-display explainer.
The claim layer
-
Copy review finds the brand promising more than the architecture supports.
Marketing inherited a sentence describing a watch, ring or app as sensing, or repeated a performance figure with no documentation behind it.
- Run the boundary verification from section 3 against every asset — product page, packaging, store listing, paid creative — before publication.
- Keep the prohibited-claims register in section 9 attached to the content workflow, and review the system overview page for what is documented.
The ownership layer
-
Nobody can say who is accountable for a data problem.
The workflow was never mapped to owners, so each party assumed another held the layer.
- Re-run the ownership table in section 4 with both parties present and record an owner per hop. A hop without a named owner is an incident waiting for a date.
- Confirm the system-side data scope on the registered system page.
The territory layer
-
A territory route stalls after the commercial terms are agreed.
Registration was planned against imagery rather than documents, so the required documentation set arrived incomplete.
- Start the documentation request in section 6 at the same time as the commercial discussion, not after it. Registration timelines are set by the market, not by the supplier.
-
The programme is compared unfavourably on a number it never published.
A competitor published a performance figure this system does not publish, and the gap was read as a weakness rather than as an evidence state.
- Brief commercial teams on the difference between "we cannot publish this" and "this is worse". The honest position is a differentiator when it is explained once, in advance.
8. Three programme shapes, and what each still has to confirm
The architecture is identical across programme types; what differs is the question that has to be answered before launch. A health brand adding a connected line has to settle its public claim boundary first, because that boundary determines the product story. A distributor preparing a territory route has to settle documentation first, because the route is gated on it. A digital-health team building a monitored programme has to settle the ownership map first, because the integration work cannot be scoped without it.
In all three cases the same discipline applies: put the unresolved items in writing and treat a non-answer as information. A supplier who cannot state the sensing method, the compatibility matrix or the data controller is telling you where the programme's risk will sit.
9. The supplier question checklist and the prohibited-claims register
Put these to the supplier in writing, and keep the answers with the evaluation record. Each question is phrased so that a non-answer is also informative.
Architecture and sensing
- Which physical part of the system obtains the measurement, and is it separate from every display device?
- What sensing method is used, and is the sensor factory-calibrated or calibrated by the wearer?
- What is the documented wear period, and what document establishes it?
- What is documented about reading cadence and about signal behaviour at the start and end of a wear period?
Display and compatibility
- Which watch models, firmware versions, phone operating-system versions and app versions are actually tested?
- Can a display device be used to obtain a reading without the adhesive sensor being worn? (The expected answer is no — if the answer is anything else, stop and re-read the material.)
- What does the display show when the transfer link is unavailable?
Data and integration
- Where does data reside, and under whose control, at every hop from sensor to platform?
- What export interface and format exist, and under what licence terms?
- Is an SDK or API available, and what is the support and versioning commitment?
Documentation and territory
- For every registration number you intend to reference: holder, covered product or model, scope, validity and intended use.
- What is the exact shipping configuration, in writing, including every accessory?
- Which document does the supplier provide, and which does the importer have to obtain in our target territory?
- What validation documentation exists behind any performance figure we may wish to publish?
Prohibited-claims register
Attach this register to the content workflow and check every asset against it before publication. Read it as a documentation test, not a blanket ban: a performance figure becomes publishable once the document behind it is in hand, and some figures in this category do have one. What the register blocks is repeating a number whose source you cannot produce.
- Any statement that a watch, ring, band or phone measures glucose, however it is phrased.
- The phrase "non-invasive glucose sensing", or any mechanism claim of that class.
- Any accuracy figure, MARD-style value or validated-algorithm claim without the document that establishes it. With the documentation a MARD figure is publishable — as a population mean, not a per-reading bound.
- Any wear duration, reading interval or update cadence published as a confirmed property without the document that establishes it.
- Any water-resistance rating stated as a permission rather than a limit. "Swimming", "hot spring" and "submersion" claims are out; a stated immersion limit is not.
- Any statement that a component is registered, cleared, approved or authorized in a market where no registration is held. A registration held in one market may be named as exactly that — scoped to that market.
- Any diagnostic, treatment, dosing or clinical-outcome claim, or any claim of replacing a clinician, a laboratory test or a fingerstick meter.
- Any MOQ, lead time, price, subscription structure or compatibility list that the supplier has not confirmed in writing.
Where to go next
If the evaluation route above raised the question of why a worn sensor is required at all — and why the number on the screen is not the raw measurement — the sensor-to-display architecture explainer works through the mechanism and the limits. If you need the current state of this specific system, the CGM & Connected Monitoring overview carries the architecture, the data workflow and the record of every claim still pending verification, and the S10 system page carries the component-level specification.
CGM & Connected Monitoring Overview — architecture, workflow and pending-verification record CGM System Architecture: From Sensor to Display S10 Continuous Glucose Monitoring System OEM & ODM development programmes Request the system documentation set
Frequently Asked Questions
Frequently Asked Questions
Questions buyers usually need answered first
Practical answers about product selection, everyday use and planning your project.
Visit the FAQ pageShould a programme choose the sensor first or the data workflow first?
The workflow first. The destination determines what the system has to hand off — export format, cadence, retention and who is accountable for the data — and those requirements can eliminate a candidate system before any hardware comparison happens. Starting from the sensor means discovering the mismatch after the integration work is scoped, which is the most expensive point to discover it.
How do we compare two CGM systems when both spec sheets say the same thing?
Compare on architecture rather than on bullets. Ask how many physical parts the system has, which part senses, which part displays, what the user sees when the display device is absent, and what each part's failure looks like from the wearer's side. Feature lists in this category converge because they are written to converge; part counts and role boundaries do not.
Who is responsible when a reading fails to appear on the display device?
Whoever agreed to own that hop in writing — and if nobody did, that is the finding. In a two-part architecture the failure is visible at the display even when the cause sits upstream, in the sensor, the transfer link or the phone's background permissions. Map every hop from acquisition to platform support and name an owner for each before launch, with a defined escalation route when a gap exceeds the tolerance you set.
What documentation should we have in hand before we list the system in our market?
The system specification; the verified display-device and app compatibility list; the kit contents in writing; and, for every registration number you intend to reference, the holder, covered product or model, scope, validity and intended use. Continuous glucose monitoring systems are regulated as medical devices in most markets, and registration is territory- and model-specific, so also confirm which documents the supplier provides and which the importer must obtain in your territory. This guide does not treat any market's requirements as already satisfied.
What are the warning signs that a connected monitoring programme is drifting?
Three show up early. Marketing copy describing a watch, ring or app as sensing rather than displaying. Readings that look unusual being handled without a defined route, so each case is improvised. And data ownership that nobody can state at the hop level. Each one is cheap to fix before launch and expensive afterwards, because all three end up in front of a customer.