Solutions · Digital Health Businesses
Connect a Measurement Device to Your Digital Health Workflow
Start with the workflow, not the device. Define the measurement need, trace how data should move, assign ownership across device, app and platform layers, and decide what must be proven in a pilot.
Built for telehealth providers, health-platform teams and clinic networks, this page separates confirmed capability from project-specific questions such as interfaces, permissions, security evidence and deployment scope.
Where You Are Standing
Three Organisations, Three Different First Questions
The decisions below are the same for everyone. What differs is which one is blocking you today. Find your situation and start there.
Telehealth & Remote-Monitoring Providers
You run a service, not a hardware business. You need a measurement device that feeds a care workflow, and you need to be able to say what it is for without overclaiming what it proves.
The device families here are documented at category level with their measurement architecture and use limits stated openly, and the claim boundary that a connected service has to respect is published in writing rather than discovered after launch.
Write the intended use before you look at hardware — it eliminates candidates faster than any comparison table. Start with the selection procedure.
Health-Platform & App Companies
You already own the software layer. What you need is a compatible measurement device — or a clear answer about the integration path to one — without building hardware.
The documented capability areas include wireless device/app data transfer, customer-app integration, and a cloud health platform with third-party service integration. The layer allocation below states which parts are ours and which are yours.
Bring the interface questions to the first conversation: SDK/API documentation, data residency, supported languages and app publishing ownership are open items we would rather name than assume.
Clinic-Network Digital Health Teams
You are deploying across more than one site, so device provisioning, participant onboarding, data-sharing authorization and escalation all have to be operational rather than theoretical.
The pilot-to-scale stages below are expressed as gates rather than as a timeline, and the pilot guide is built around the operational questions that decide whether a roll-out is fundable.
Plan the pilot around a written question and a data-flow map with an owner on every hop — then decide about scale with the support load known rather than guessed.
Strategy: Dependency Order
The Five Decisions an Integration Turns On
These are gates, not steps. Each one is expensive to reopen, which is why the order matters more than the speed.
Intended use
What is measured, on whom, read by whom, and what your organisation will say about the reading. This comes first because it is the only input that can disqualify a device family before any comparison happens, and because it is the same statement that bounds what you may publish.
If deferred: Deferred, this becomes a claim problem: the hardware arrives, the service is designed, and the promise the organisation wants to make turns out to be one the device cannot support.
Device selection
Which family and which model, chosen against the intended use rather than against a feature list. The three families are positioned by what a workflow would use them for and by what each must not be taken to do — and the model-level detail lives on the product pages, not here.
If deferred: Deferred, this becomes a re-selection: the device is bought for a workflow it does not fit, and the cost lands on the onboarding programme rather than on the purchase order.
Data path
How a reading actually leaves the device and reaches the person who acts on it. In practice this is a chain of six hops — device, transfer path, application or cloud layer, receiving platform, review point, and the person who acts — and each hop needs an owner before the pilot, not after it.
If deferred: Deferred, this becomes an integration surprise: the plan assumes a bridge between two systems that nobody has confirmed exists, and it is discovered during a live deployment.
Platform-layer ownership
Which layer the integrating organisation operates and which the device supplier provides. This is the decision that determines who answers a participant question, who investigates a missing reading, and who owns the record the service depends on.
If deferred: Deferred, this becomes an unowned incident: a reading does not arrive, and no one can establish whether the device, the transfer path or the receiving platform was responsible.
Data-sharing authorization
Whose data it is, who may see it, on what documented basis, and how withdrawal is handled afterwards. This is treated as an architectural requirement rather than as paperwork, because a workflow that cannot evidence its basis for sharing measurement data has no defensible operating position.
If deferred: Deferred, this becomes a compliance problem: the service is live, the data has already been collected, and the basis for holding it has never been reduced to a document.
The data path, hop by hop
Decision 3 is the one buyers most often skip, so it is worth making concrete. A reading travels six hops before anything happens because of it:
the device → the transfer path → the application or cloud layer → the receiving platform you operate → the review point → the person who acts on the reading
Every one of those hops needs a named owner and an identified failure symptom before a deployment, not after it. The interface specifics that sit behind those hops — what data can move, over what mechanism and hosted where — remain open items that have to be confirmed in writing. Naming them is the point; a grid of assumed integrations would be worth less than the paper it was printed on.
Starting Points
Three Families, Positioned by Workflow Fit
This table is deliberately not a specification comparison. It answers which family fits which kind of workflow, and what each one must not be taken to do.
| What It Is | Form Factor and Wear Model | Where the Measurement Comes From | What It Feeds in a Workflow | What It Must Not Be Taken To Do |
|---|---|---|---|---|
| Wrist blood-pressure watch family (VC60, VC61, VP20, VP21) | A wrist-worn watch with a dedicated airbag measurement architecture, in round and rectangular formats. Worn continuously; measured deliberately. | The watch itself obtains the blood-pressure measurement through the airbag and pump architecture described in the source material. | A per-measurement reading that a participant can take on a schedule and that a service can review as part of a monitoring routine. | It is not a diagnostic instrument, does not guarantee accuracy, and its IP67 rating covers short-term shallow immersion only — no swimming and no hot water. |
| Smart ring family (CARE2) | A ring worn on the finger as an everyday item. Continuous everyday wear rather than scheduled measurement sessions. | Sensors in the ring itself, as described in the source material. Everyday health and activity data. | A continuous everyday data stream for wellness-oriented services where scheduled measurement is not the use case. | It is for daily use only — no swimming, no hot springs, no prolonged submersion — and nothing here supports disease-screening inference. |
| CGM & connected monitoring family (S10) | A separate single-use adhesive sensor applied to the upper arm, plus a watch and app that display the synchronized data. | The adhesive sensor obtains the measurement. The watch and app are display endpoints: they present what the sensor obtained. | A stream of sensor readings that a connected monitoring service can display and route — subject to the intended-use and documentation requirements that apply to this family. | A watch or app showing a glucose value is displaying a reading it did not measure. There is no non-invasive glucose sensing here, and no watch measures glucose. |
Blood Pressure Watches
Four models — VC60, VC61, VP20 and VP21 — with the model-level specification detail on their own pages.
Smart Rings
The CARE2 family, for everyday-wear data streams where scheduled measurement is not the use case.
CGM & Connected Monitoring
The S10 separate adhesive upper-arm sensor, with a watch and app that display the synchronized data.
Selecting within a family is a procedure, not a comparison — write the intended use first, choose the connectivity operating model deliberately, then plan the measurement protocol and the training burden it creates. That procedure is set out in full in the device selection guide. For custom development, branding or a private-label programme built on any of these families, see the OEM&ODM process or the Health Brands & Distributors path.
Strategy: Layer Allocation
Which Part of the Platform Is Yours
Integration conversations go wrong when nobody writes this down. Layers are listed as responsibilities, not as capabilities.
Your Side — the Integrating Organisation
- Participant identity — who the person is in your system, and how they are enrolled
- The authorization record — what each participant agreed to, on what basis, and when it was withdrawn
- The care-side review workflow — who looks at a reading, in what queue, and on what schedule
- The escalation route — what happens when a reading needs a human decision
- Hosting and retention of the receiving system you operate
These sit with you because they carry your organisation's obligations to the people you serve. Nobody else can own them on your behalf.
Supplied Side — LUROGEF
- The device and its firmware
- The companion-app baseline
- The device-to-app data transfer
- The cloud health platform with third-party service integration, as described in company materials
These are documented capability areas. They describe what exists, not a promise about a specific interface — see the open items below.
Open Items — Confirmed in Writing, Not Assumed Not confirmed
- SDK/API documentation availability and the concrete interface scope per family
- Supported integration patterns and which of them are documented versus enabled case by case
- Data residency, retention defaults and hosting location for any cloud layer
- Supported languages and app publishing ownership
These four are the questions that most often decide whether an integration is straightforward or expensive, and they are the ones we will not answer with an assumption. If a supplier shows you a compatibility grid without being able to produce the interface documentation behind it, that is the moment to slow down.
Strategy: Staging
From Requirement to Scale, as Gates
Six stages, expressed as sequence and dependency. No stage carries a duration or a device count, because none of those figures is verified.
Requirement and intended use
The written statement from Decision 1, plus the operational requirement it implies: who measures, who reads, and what happens outside the expected range.
Output: a one-page requirement. Nothing downstream can be evaluated without it.
Device selection and documentation
Family and model chosen against the requirement, together with the document categories the buyer must hold before committing — and the scope line read on each one.
Output: a selected device plus the documentation package. A certificate out of scope is not a substitute.
Integration and interface confirmation
The interface questions settled in writing: what data can move, over what mechanism, hosted where, and who owns the app side. This is the stage where open items become answers or become blockers.
Output: a confirmed interface scope. Unanswered items here are the ones that stop a deployment.
Bounded pilot
A trial against a written question, with an owner on every data hop and the authorization step exercised — including withdrawal.
Output: evidence that the operational chain completes. Not evidence of clinical effect.
Review against non-clinical criteria
Assessment against logistics, participation and data-completeness measures: provisioning completion, onboarding completion, measurement-session completion, transfer reliability, data completeness at the receiving end, and the support load actually generated.
Output: a fundable or unfundable scale decision. Clinical-outcome criteria are excluded by design.
Scale decision and operational ownership
If the pilot answered its question, the scale decision is about capacity and support — how many onboarding sessions can be staffed, what the replacement policy is, and who owns each layer at volume.
Output: an operational owner per layer. No stage on this page carries a duration or a device count.
Stage 4 is where most of the risk sits, and it has a guide of its own: how to plan a connected monitoring pilot — scope, the variables a device count depends on, the six-hop owner map, the authorization worksheet, success criteria that are not clinical-outcome claims, and an honest account of what a pilot cannot prove.
Strategy: Reported Evidence
One Implementation, Reported as Company-Reported
This is the only implementation that can be described, and it is described in the exact terms the company reports it — including the condition attached to it.
Connecting LUROGEF Watches to Longgang Family-Doctor Services
LUROGEF reports the launch of a family-doctor service point at the Longcheng China Telecom business hall in Shenzhen's Longgang District. The service combines family-doctor enrollment, a health-service package and a LUROGEF blood-pressure watch. With residents' authorization, watch data can be shared with the Longgang family-doctor platform for review by their contracted doctors.
Reported by the company; not an independently verified deployment record. The authorization condition above is not a formality in this description — it is stated as the condition under which the data may be shared at all.
What This Does Not Establish
- No clinical effectiveness, and no treatment outcome.
- No patient or participant adoption count.
- No hospital, centre or site count, and no claim that any site is fully active.
- No service uptime, availability or nationwide coverage.
- No "first" or exclusivity claim, which would require independent substantiation.
- No customer, partner, hospital or platform name is presented as an endorsement, and no logo is used.
We print this list next to the description on purpose. An integration story without its limits attached is a marketing claim, and you would be the one repeating it to your own stakeholders.
Strategy: Boundary
What No One Should Say About This Portfolio
These four statements are published so that a deploying organisation can repeat them accurately. The claim you publish becomes your claim.
No certification or registration claim in any market
No product on this site is claimed to be certified or registered in any market. A production licence and a quality-management certificate are factory and process documents with a bounded scope; RED and RoHS declarations relate to named models and named directives only. None of them is a product authorization, and none of them should be presented as one inside a service.
No diagnosis, no guaranteed accuracy, no treatment outcome
The portfolio supports measurement and monitoring workflows. It does not diagnose, does not guarantee accuracy, and does not deliver treatment outcomes. Any service built on it has to be described the same way, because the claim a deploying organisation publishes becomes its own claim.
Water and wear limits are part of the product, not a footnote
The watch IP67 rating covers short-term shallow immersion only — no swimming, no hot water. The ring is for daily use only — no swimming, no hot springs, no prolonged submersion. These are operating limits that affect how a service instructs participants, so they belong in the onboarding material rather than in small print.
For CGM, the sensor senses and the display displays
The S10 is a separate single-use adhesive sensor worn on the upper arm. A connected watch and the companion app only display synchronized data from that sensor. This distinction is the single most important boundary in this family, because a workflow that assumes the watch measures glucose has modelled the system incorrectly.
Strategy: Validation
What We Need From You, and What You Should Get From Us
An integration conversation moves fastest when both sides arrive with their open items already written down.
Bring to the First Conversation
- The intended use, in writing: who measures, who reads, and what your organisation will say about a reading.
- The data path you intend to operate, and the six hops you already know you own.
- The authorization basis you intend to rely on, and who in your organisation owns it.
- The scale you are planning towards, and the onboarding capacity you can actually staff.
Ask Us for in Writing
- The interface scope for the family you are considering, and the documentation behind it.
- The document categories applicable to the specific named model and its directives.
- Hosting, data residency and retention defaults for any cloud layer.
- The replacement policy and the operational support model, so the pilot's support load is a known quantity rather than a surprise.
- Commercial terms — order quantity, tooling or setup charges, sample terms and lead time.
Items still being confirmed are marked on this page rather than estimated. Where we will tell you straight yet, we will say so.
Integration Guides
How to Select a Measurement Device for a Remote Monitoring Workflow
An integration-side selection procedure: write the intended use before you look at hardware, choose cellular or Bluetooth Low Energy as an operating model rather than a feature, plan the measurement protocol and the training burden it creates, and obtain the documentation a buyer must hold — including the scope line on every document.
How to Plan a Connected Monitoring Pilot
A pilot-planning instrument for connected monitoring: define the written question the pilot answers, derive device count from your own onboarding capacity instead of a published figure, map the six data hops and name an owner for each, settle the authorization questions including withdrawal, and agree success criteria that are deliberately not clinical-outcome claims.
Frequently Asked Questions
Questions buyers usually need answered first
Practical answers about product selection, everyday use and planning your project.
Visit the FAQ pageHow does a measurement actually get from the device into our workflow?
As a chain with hops, and each hop needs an owner. The reading is obtained by the device, leaves it over a wireless link, passes through the application or cloud layer, arrives at the receiving platform you operate, is surfaced at a review point, and then reaches the person who acts on it. Company materials document wireless device-to-app data transfer, customer-app integration and a cloud health platform with third-party service integration. What is not confirmed — and has to be settled in writing before you plan around it — is the concrete interface scope: SDK/API documentation, protocol parameters, supported languages and data residency are all open items. We would rather name them as open than publish a compatibility grid we cannot confirm.
Who is responsible for what once the service is live?
Split by layer. You own participant identity, the authorization record, the care-side review workflow and its escalation route, and the hosting and retention of the receiving system — because those are the parts that carry your organisation's obligations to the people you serve. The device supplier provides the device and firmware, the companion-app baseline, the device-to-app transfer, and the documented cloud platform with third-party service integration. Every interface-scope item on that second list still has to be confirmed in writing rather than assumed, and none of it is a clinical or regulatory duty.
On what basis may we collect and share someone's measurement data?
On an authorization that answers four questions: what data leaves the device, who may see it, on what documented basis, and how withdrawal is handled afterwards. That is not paperwork — it is the condition the workflow depends on. In the one implementation this company reports, the 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. What applies in your jurisdiction is a question for your own advisers; this page names the questions rather than asserting a rule.
Can we start with a small deployment and scale later?
Yes — and the sequence matters more than the size. The stages are: requirement and intended use, then device selection and documentation, then integration and interface confirmation, then a bounded pilot, then a review against criteria that are not clinical outcome measures, then the scale decision, then operational ownership at scale. No stage on this page carries a duration, a device count or a volume figure, because no verified figure exists for any of them and we do not publish estimates as if they were facts. Ask for a written schedule and a written replacement policy instead.
What should we not say about this once it is deployed?
Four things. (1) No product here is claimed certified or registered in any market — a production licence or a quality-management certificate is a factory and process document with a bounded scope, and RED/RoHS declarations relate to named models and named directives only; neither is a product authorization. (2) No diagnosis, no guaranteed accuracy, no treatment outcome. (3) The watch's IP67 rating covers short-term shallow immersion only — no swimming and no hot water; the ring is daily use only — no swimming, no hot springs, no prolonged submersion. (4) For the CGM family, the S10 is a separate single-use adhesive sensor worn on the upper arm, and the watch and app only display synchronized data from it. A watch showing a glucose value is displaying a reading it did not measure.