Challenge
Every reading out of range creates an alert
Agnotic approach
Thresholds per patient or condition, set by clinicians, with repeat readings and trends considered before an alert fires.
Remote Patient Monitoring Software
Remote patient monitoring software development
RPM programs stall when device data arrives but nobody acts on it, or when the minutes are never recorded for billing. Agnotic Technologies builds RPM software that connects devices, routes the right alerts to the care team and captures the data your billing needs, inside your EHR.
Device integrationCare team alertsBilling time captureEHR write-back
Trusted by global innovators
What is remote patient monitoring software development?
Remote patient monitoring software development is building the system that collects readings from patients' devices at home, flags the ones that need attention and helps the care team act and document. Agnotic Technologies builds RPM platforms that connect devices, route alerts, record care team time for billing and write results back to the EHR.
Remote patient monitoring means tracking health data, such as blood pressure, glucose or weight, between visits. The software is what turns those readings into care, and into a program the practice can sustain.
What does the care team see in an RPM program?
A queue of patients whose readings crossed a threshold, the reading history behind each alert, the minutes logged this period and the billing status for the month.
Alerting
How should alerts reach the care team?
Too many alerts and the team stops reading them. Too few and a patient is missed. We design the alert path with your clinical leads.
Challenge
Alerts go to everyone
Agnotic approach
Alerts are routed by severity: a work queue for routine follow-up and a faster path for readings that need same-day action.
Challenge
Missing data is invisible
Agnotic approach
Patients who stop sending readings appear in their own queue, so outreach starts before the month is lost.
Challenge
Follow-up happens outside the system
Agnotic approach
Calls, messages and decisions are logged against the alert, so the record shows what was done and when.
What do we build into an RPM platform?
The modules an RPM program needs from enrollment to billing.
Patient app and enrollment
Enrollment, consent, device pairing and reminders, on iOS, Android or both.
Device data ingestion
BLE, cellular, HealthKit and Health Connect data normalized into one reading history per patient.
Rules and alert engine
Clinician-set thresholds and routing rules that decide which readings reach which queue.
Care team workspace
Work queues, reading history, notes and time logging in one screen.
Billing time capture
Reading days and care team minutes counted per period and exported to your billing system.
EHR write-back
Readings and notes written to the EHR as FHIR Observations or HL7 v2 results, depending on your EHR.
Who it is for
Who builds RPM software with us?
Most of our RPM work is for one of these teams.
Provider RPM program leads
Practices and health systems running hypertension, diabetes or heart failure programs.
Digital health founders
Companies whose product is a monitoring program or includes one.
Chronic care teams
Care management teams combining RPM with chronic care management workflows.
Device companies
Device makers that need a care team platform around their device data.
Billing data
What data does RPM billing need?
Medicare RPM billing depends on the data the platform records. We capture it as the work happens, not afterwards.
- Patient consent to monitoring, recorded once at enrollment
- Device setup and patient education, with the date it happened
- Days with readings in each 30-day period, counted automatically
- Care team time spent on monitoring and treatment management, logged against the patient
- Interactive communication with the patient during the month
- The ordering practitioner and the condition being monitored
Reference architecture
How does RPM data flow from the device to the EHR?
The layout we start from and adjust to your devices, EHR and billing system.
Devices
- BLE devices
- Cellular devices
- HealthKit and Health Connect
Ingestion
- Phone app or hub
- Vendor data feeds
- Normalized reading store
Clinical logic
- Thresholds and rules
- Alert routing
- Missing data checks
Care team
- Work queues
- Notes and outreach log
- Time logging
Outputs
- EHR write-back (FHIR Observation)
- Billing export
- Program reporting
Device connectivity
How do devices connect: BLE, cellular, HealthKit or Health Connect?
The connection method shapes setup, cost and how reliably readings arrive. Many programs use more than one.
Bluetooth Low Energy (BLE)
- Device pairs with the patient's phone app
- Works with many consumer and clinical devices
- Needs a phone nearby and app permissions
Cellular devices
- Device sends readings over a cellular network
- No phone or app setup for the patient
- Higher device cost; vendor data feed to integrate
Apple HealthKit
- Reads data the patient already collects on iPhone
- Patient grants access per data type
- Data quality depends on the source device
Android Health Connect
- Shared health data store on Android
- Patient grants access per data type
- Device and app coverage varies
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Compliance and security
What compliance and security requirements apply to RPM software?
Each requirement is an engineering decision we make with your clinical and compliance leads. Agnotic claims no certification; we build so your program can pass the reviews it needs.
| Requirement | Who sets it | What it means for the build |
|---|---|---|
| HIPAA Security Rule | HHS | Access control, audit logs and encryption for readings, notes and messages, on the phone and in the cloud |
| Business associate agreements | HHS (HIPAA) | A signed BAA with device data vendors, cellular platforms and hosting providers that handle PHI |
| Device software rules | FDA | Features scoped so you know whether any of them would be regulated as a medical device |
| Medicare RPM billing | CMS | Consent, reading days and care team minutes recorded so billing follows current CMS rules |
| Accessibility | W3C (WCAG 2.2) | Patient apps designed to WCAG 2.2 so older patients and people with disabilities can use them |
| EHR data exchange | HL7 International and ONC (ASTP) | Readings written to the EHR as HL7 FHIR Observations, using the APIs certified EHRs offer |
How we work
How does an RPM engagement with Agnotic work?
Three stages, each with a clear output.
1.
Scoping call
We agree the conditions, devices, care team workflow, EHR and billing approach for the program.
Program first2.
Fixed-scope first release
One condition and one device type working end to end, from reading to alert to billing export, with weekly demos.
Weekly demos3.
Scale and support
More devices, conditions and integrations, then ongoing releases and support under agreed terms.
Ongoing releasesScope and effort
What drives the scope, timeline and cost of RPM software?
We do not quote before we understand these. They are what a scoping call works through.
Devices
Each device type and connection method (BLE, cellular, HealthKit, Health Connect) adds integration and testing.
Conditions
Each condition needs its own thresholds, alert rules and care team workflow.
EHR
Writing readings and notes back to the EHR, and which EHRs are involved.
Billing
How time and reading days are captured and exported to your billing system.
Patient apps
iOS, Android or both, and the languages and accessibility needs of your patients.
Scale and security review
Patient volume, uptime needs and the depth of your security review.
Decision table
Should you buy an RPM platform or build your own?
Many programs start on a packaged platform. Building makes sense when the program becomes part of your product or your care model.
| Question | Buy a packaged RPM platform | Build your own |
|---|---|---|
| How fast do you need to launch? | Quick start for a standard program | Longer first release, shaped to your program |
| Who owns the data and the patient experience? | The vendor's app and data model | Your app, your data model, your brand |
| How many device types? | Limited to the vendor's device list | Any device or data source you choose to integrate |
| How does it fit your EHR? | Depends on the vendor's integrations | Built for your EHR and workflow |
| How does cost behave as you grow? | Per-patient or per-device fees | Build and run costs you control |
A common path is to launch on a packaged platform, then build once the program's workflow and volume are proven.
Facts and sources
Which rules and facts shape an RPM build?
Short facts we design around, each linked to its primary source.
Medicare's remote physiologic monitoring codes include CPT 99453, 99454, 99457 and 99458, and the CY 2026 Physician Fee Schedule added 99445 and 99470 for shorter monitoring periods and shorter management time.
Source: Federal Register, November 5, 2025 (CY 2026 Physician Fee Schedule final rule, CMS-1832-F)FDA's guidance on device software functions focuses oversight on software that meets the definition of a medical device and could put patient safety at risk if it does not work as intended.
Source: FDA, Policy for Device Software Functions and Mobile Medical Applications (2022)The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
Source: 45 CFR Part 164 Subpart C (eCFR)A HIPAA covered entity may share protected health information with a business associate, such as a software vendor, only under a business associate agreement that commits the vendor to safeguard it.
Source: 45 CFR 164.502(e) and 164.504(e) (eCFR)
Frequently Asked Questions
Blood pressure cuffs, glucose meters, scales, pulse oximeters and wearables, over Bluetooth Low Energy, cellular feeds, Apple HealthKit or Android Health Connect. We confirm each device's data access before we commit to it.
The platform records consent, setup, days with readings and care team minutes as the work happens, then exports them per billing period. Your billing team decides which codes to bill; the software makes sure the data behind them is there.
Buy if a packaged platform supports your devices, workflow and EHR, and its per-patient fees work at your volume. Build when the program is part of your product, needs devices the vendors do not support, or must fit your own workflow.
It depends on what it does. Software that only collects and shows readings is treated differently from software that analyzes them to suggest treatment. We help you scope features with FDA's device software guidance in mind, and your regulatory team makes the call.