The best remote patient monitoring platform depends on what you are building: a clinic that wants to run an RPM program needs a finished white-label app, while a company building its own RPM product needs device integration, a clinical data model, alerting and access control it can build on. This guide is for the second group. It explains what to look for in a remote patient monitoring platform, how the three main approaches compare, how reimbursement differs between the EU and the US, and where Ovok fits.

Key takeaways

Decide first whether you are buying an RPM service or building an RPM product. The right platform category follows from that.
Device integration is the hardest part of RPM. Check exact device models, connection paths (Bluetooth, cellular, health platforms) and how readings are normalized.
Store readings in a standard clinical model such as FHIR Observations, so dashboards, EHR exports and analytics all read the same data.
Alerting is clinical logic. Who sets thresholds, who reviews alerts and which component carries a medical-device status must be explicit.
Reimbursement is national. The US uses CPT codes for remote physiologic monitoring; in Europe, programs such as Germany's heart-failure telemonitoring and France's télésurveillance follow their own rules.
Ovok combines supported device data, a FHIR R4 backend and optional Signals evaluation for enrolled patients, so your team builds the app on top.

Buying RPM vs building RPM

Many "best RPM platform" lists compare turnkey programs for clinics: they ship devices to patients, provide a patient app and a nurse dashboard, and help with billing. That is the right answer if you are a provider who wants to start monitoring patients next month.

If you are a digital-health company, a medtech manufacturer or a provider group building its own experience, a turnkey app gets in the way. You need to own the patient app, the brand, the care workflow and the data. What you want from a platform is infrastructure: device connectivity, a clinical record, identity and authorization, and possibly a regulated alert engine you do not have to certify yourself.

What to look for in a remote patient monitoring platform

1. Device integration

Ask these questions for every device you plan to support:

Which exact models are supported? A brand name is not enough; firmware and model variants matter.
How does data travel? Bluetooth to a phone app, a cellular gateway, a vendor cloud, or a health platform like Apple HealthKit or Android Health Connect.
Who owns the pairing experience? In a phone-based flow, your app guides the patient through pairing and measurement.
How are readings normalized? Units, codes and timestamps should be consistent across manufacturers.
Can you test it? Bluetooth needs a physical phone and device; simulators do not reproduce the full flow.

2. A clinical data model

Readings should land in a standard clinical model, not a vendor-specific JSON blob. FHIR is the common choice: a blood-pressure reading becomes an Observation with LOINC codes and components for systolic and diastolic values, linked to a Patient and a Device. This matters later when you export to an EHR, run analytics or switch vendors. If FHIR is new to you, start with What is FHIR? and our FHIR API search guide.

3. Alerting and thresholds

Alerts turn data into work for clinicians. Look for:

Patient-specific thresholds set by a clinician, not only global defaults.
A clear model for alert episodes, acknowledgement and notes, so the same problem does not page staff on every new reading.
An explicit regulatory boundary: software that evaluates physiological data to inform clinical decisions can be a medical device under the EU MDR. Know which component makes the alert decision and what its status is.

4. Clinician workflows

Clinicians need patient lists, measurement history, trends and a fast path from an alert to the patient's context. Some platforms ship a finished dashboard; infrastructure platforms give you APIs and example apps to build your own. Either way, check how real-time updates reach the dashboard (polling vs push). Our guide to real-time FHIR subscriptions explains the options.

RPM data is health data. You need patient and practitioner sign-in, per-patient authorization, care-team relationships and, for B2B products, separate tenants per clinic customer. Make sure the platform distinguishes "this practitioner is on the care team" (a relationship) from "this practitioner may read this patient's data" (an authorization rule).

6. Hosting and data protection

For European patients, look for EU hosting, a GDPR Article 28 data processing agreement and an audit trail. For US patients, HIPAA and a BAA. If you sell in both markets, check that the platform supports separate deployments or regions.

7. Pricing that matches your business model

RPM businesses usually earn per enrolled patient per month. Platforms priced per monitored patient keep cost and revenue aligned; platforms priced per device, per API call or per seat can still work but need careful modelling.

EU vs US reimbursement context

Reimbursement shapes product requirements, so it is worth understanding before you choose a platform.

United States: CPT codes for remote physiologic monitoring

Medicare pays for remote physiologic monitoring (RPM) through CPT codes. According to the CMS CY 2026 Physician Fee Schedule final rule, the 2026 code set includes:

99453: initial set-up and patient education on the monitoring equipment.
99454: device supply with data transmission for 16 to 30 days in a 30-day period.
99445: new for 2026, device supply for 2 to 15 days in a 30-day period. It is billed instead of 99454, not in addition.
99470: new for 2026, the first 10 minutes of RPM treatment management in a month.
99457 and 99458: treatment management for the first 20 minutes and each additional 20 minutes.

The CMS Telehealth & Remote Monitoring booklet (December 2025) adds requirements that affect product design: an established patient relationship, patient consent, data collected electronically and uploaded automatically, a device that meets the FDA definition of a medical device, and only one practitioner billing remote monitoring per patient in a 30-day period. Your platform therefore needs reliable day counts of transmitted data and time tracking for clinician work. CMS has proposed further changes for 2027, so check the current rule before you build billing logic.

Europe: national programs, not one code set

There is no EU-wide RPM billing code. Reimbursement is decided country by country:

Germany: the Federal Joint Committee (G-BA) added telemonitoring for heart failure to statutory care with a decision in December 2020. It is organised around a primary treating physician and a telemedicine centre, using implanted cardiac devices or external devices that record at least weight, heart rhythm, blood pressure and general health status.
France: télésurveillance médicale moved into common-law reimbursement on 1 July 2023, with a monthly per-patient payment for the monitoring team and separate payment for the digital medical device, for indications on the official list (LATM).

For a European RPM product, this means two things. First, your data model must support the indication-specific measurements each program requires. Second, the regulatory status of the alerting component matters for reimbursement and hospital procurement.

Three approaches compared

White-label RPM apps

Turnkey platforms give clinics a finished patient app, a clinician portal and device kits. Health Recovery Solutions, for example, offers PatientConnect for patients with customizable monitoring kits and the ClinicianConnect portal, which integrates with EHR systems.

Strengths: fastest path to a running program; logistics and workflows are handled.
Trade-offs: limited control over the patient experience, brand and data model; hard to build a differentiated product on top.

Device-data APIs

These platforms aggregate devices and wearables behind one API. As of October 2026, Validic describes a data layer that normalizes 700+ devices and managed programs that write to EHRs; Tenovi offers cellular-connected devices behind a single API; Thryve connects 500+ wearable and health data sources and states it is developed and hosted in Europe; Vivalink provides wearable sensors with an SDK for clinical research and remote monitoring.

Strengths: broad device coverage, normalized data, often cellular options that avoid phone pairing.
Trade-offs: you still need a clinical record, identity, authorization, alerting and the apps. Many are US-first; check EU hosting for each.

FHIR backends built for monitoring

A FHIR backend gives you the clinical record and APIs; some add devices, identity and SDKs. This is the "build your own product" category. Our comparison of the best digital health backends for European startups covers the general-purpose options such as Medplum, Aidbox and the hyperscaler FHIR stores.

Strengths: you own the product and the data model; standards make EHR integration and vendor changes easier.
Trade-offs: you build the apps; general-purpose FHIR servers leave device ingestion and alerting to you.

Where Ovok fits

Ovok is a FHIR backend for remote monitoring, designed for teams that build their own patient and clinician apps. It brings three pieces together:

Supported devices through the Native SDK

The React Native SDK (@ovok/native) supports 50+ devices, including blood-pressure monitors, sleep radars, SpO₂ monitors, urine analysers and wearables. Your app owns the pairing and measurement experience; the SDK handles Bluetooth discovery and measurement callbacks. The supported-device catalog lists exact models and measurements, and the SDK also imports selected HealthKit and Health Connect records as FHIR Observations. Connected systems can send data through the mTLS-protected Ovok IoT Service, set up with the Ovok team.

FHIR R4 records

Supported readings are stored as FHIR Observations in an R4 backend you can query over REST or GraphQL. Questionnaires, medication resources, goals, care plans, CMS content and video calls are available for the rest of the care workflow. Access Policies control who can read and write which resources; a care-team relationship alone does not grant access. Hosting is on AWS Frankfurt.

Signals for enrolled patients

Signals is optional. Your team configures Signals enrollment per patient; only eligible vital-sign readings from enrolled patients are sent to Signals for alert evaluation. Signals evaluates patient-specific rules, including thresholds a practitioner sets, and returns alert decisions that your app reads through Ovok, with APIs for alert episodes, acknowledgement and notes. Signals is MDR Class IIa. Ovok itself is not a certified medical-device product, and an app built on Ovok does not inherit Signals' status.

What your team still owns

The patient and clinician apps, brand and user experience.
Intended use, enrollment and consent.
Clinical interpretation, escalation and staffing.
Regulatory strategy for your product.

To see the pieces working together, the example RPM repositories include a patient mobile app, a clinician dashboard and a clinic EHR, and the remote patient monitoring use case shows the architecture.

A checklist for your platform evaluation

List the exact device models and measurements for your first indication.
Confirm how each device connects and test one with a physical phone.
Map each reading to a FHIR resource and code.
Define who sets thresholds and who acts on alerts, and which component makes the alert decision.
Check hosting region, DPA or BAA, and audit trail.
Model platform cost per enrolled patient against your expected reimbursement or subscription revenue.
Build one end-to-end flow: pair, measure, store, show to a clinician, raise an alert.

FAQ

What is a remote patient monitoring platform?

A remote patient monitoring platform collects health measurements from patients outside the clinic, usually through connected devices, stores them and makes them available to care teams, often with alerts when values leave a defined range.

What is the difference between an RPM app and an RPM platform?

An RPM app is a finished product for patients and clinicians. An RPM platform is the infrastructure underneath: device connectivity, data storage, identity and alerting that you use to build your own app.

Which devices work with Ovok?

The Native SDK supports 50+ devices across blood-pressure monitors, sleep radars, SpO₂ monitors, urine analysers and wearables. Check the supported-device catalog for exact models before you commit to a workflow.

Are the US CPT codes relevant in Europe?

No. CPT codes such as 99453, 99454, 99457 and 99458 apply to US billing. European countries have their own programs, such as heart-failure telemonitoring in Germany and télésurveillance in France.

Does every reading go to Signals?

No. Signals enrollment is configured per patient, and only eligible vital-sign readings from enrolled patients are sent for alert evaluation. Other data stays in the FHIR workflow.

Do I need FHIR for remote monitoring?

You can build RPM without it, but FHIR gives you a standard model for readings, patients and devices, which makes EHR integration, analytics and future vendor changes much easier.

Conclusion

The best RPM platform for a product team is the one that handles devices, the clinical record and alerting boundaries well, while leaving the product in your hands. If you are building your own monitoring product, start in the free Developer sandbox, read the Ovok docs, and check pricing per monitored patient against your business model.