Remote patient monitoring
Remote patient monitoring software built around your EHR
Hashlogics builds remote patient monitoring that collects device readings, alerts a nurse when a threshold is crossed, and files the record into your EHR.
- 4.8 on Clutch across 22 reviews
- PremiumAudit.io: audit cycle cut 75%, calculation errors cut 95%
- In production for SmartREI, Tankaware, ZyloBase, KiwiWrite
What an RPM build has to get right
5 things that decide this
- 01Remote patient monitoring software moves a reading from a cuff, scale, glucose sensor or pulse oximeter into a place where a nurse can act on it, and then into the patient's chart.
- 02Your device data arrives one of two ways: from the device maker's cloud through its developer API, or straight from the device to a phone app over Bluetooth. That choice decides most of the build.
- 03Thresholds belong to the clinician, not the software. You set the limits per patient, and every alert lands in a review queue with a named nurse and a time stamp.
- 04CMS ties RPM billing to days with readings and to minutes of clinical staff time each month. The software counts both, so your billing team isn't rebuilding them from spreadsheets.
- 05Every vendor that touches a reading for your clinic needs to sit inside a business associate agreement, including the device maker's cloud.
Who builds remote patient monitoring software for clinics?
Hashlogics builds RPM software for clinics and home care agencies that run Epic, athenahealth, eClinicalWorks or another EHR. Readings come in from connected devices such as Withings or Dexcom, rules flag the ones out of range, and a nurse reviews each alert before anything is filed. Both the record and the time spent go into your EHR, so billing and care notes match.
You can also buy an off-the-shelf RPM platform, and many clinics should. A build makes sense when your device mix, your alert rules or your EHR setup don't fit what those platforms do, or when RPM is part of a larger product you sell.
How do readings get from the device to your system?
There are two common paths. Most programs end up using both, because no single device maker covers every reading you need.
| Question | Vendor cloud API | Direct Bluetooth app |
|---|---|---|
| How data arrives | The device syncs to the maker's cloud; we pull readings through its developer API. | Or it pairs with a phone app we build, which sends readings to your backend. |
| Examples | Withings and Dexcom both publish developer APIs; access terms are set by each vendor. | Cuffs and scales that publish a standard Bluetooth health profile. |
| What you control | Less. You live with the vendor's sync timing and data fields. | More. You own the pairing flow, retries and offline storage. |
| What it costs you in work | Patient account linking and a vendor agreement. | A phone app to build, test across phones and keep updated. |
| Best fit | A clinic using a small, fixed set of devices. | A program with mixed devices or patients who struggle with setup. |
What happens when a reading crosses a threshold?
Each patient gets limits set by the ordering clinician: a blood pressure ceiling, a weight gain over three days, a glucose low. When a reading crosses a limit, the system opens an alert in a review queue rather than paging everyone. Each alert shows the reading, the trend before it and the patient's care plan.
A nurse picks it up, calls or messages the patient through Twilio, and records what was done. If nobody takes the alert in the time your protocol sets, it moves up to the next person on the rota. Missed readings are their own alert, because a patient who stops measuring is often the one who needs a call.
Your protocol decides who covers nights and weekends. Some clinics keep a nurse on call; others mark RPM as a daytime service and tell patients to call 911 for emergencies. The software follows whichever rule you write, and logs every hand-off.
- 01Limits set per patient by the clinician, with a record of who changed them
- 02One queue for every alert, with owner, time opened and time closed
- 03Escalation when an alert sits too long
- 04A missed-reading alert as well as a high-reading one
- DeviceCuff, scale, glucose sensor or oximeter sends a reading.
- IntakeVendor API or phone app delivers it with patient, time and device ID.
- RulesYour limits flag readings out of range or missing days.
- Nurse reviewA named nurse acts, contacts the patient and logs the time.
- EHRReadings, notes and minutes are filed to the chart.
Software never closes an alert on its own. A person does, and the time they spent is counted for the month.
What documentation does RPM billing need?
CMS pays for RPM through a small set of codes. One covers setup and patient education. Another covers the device supplying readings across enough days in a 30-day period. Others cover the minutes clinical staff spend each calendar month reviewing data and talking with the patient. CMS revised the day and minute thresholds for 2026, so we read the current Physician Fee Schedule with your billing lead before the build.
Whatever the current rule says, the clinic needs the same evidence: patient consent on file, an order from a billing practitioner, the device used, the days readings arrived, and each staff member's time with a note of what was discussed. Days and minutes per patient are counted as they happen. At month end your billing team sees which patients qualify and why, rather than adding up logs by hand.
We don't advise on what to bill. We build the record that lets your billing lead decide.
Can RPM readings go straight into our EHR?
Often, yes, but how depends on your EHR and how your health system has it set up. Epic, athenahealth and eClinicalWorks all publish FHIR R4 APIs, and some setups accept readings as discrete observations in the chart. Others only accept a document, such as a monthly summary filed to the patient's record. Where neither is open to you, alerts and summaries go to a staff queue and a person files them.
We find out which of these your EHR allows in the Blueprint, before anyone writes code. That answer shapes the whole build, and we'd rather tell you early than promise a write-back your EHR won't take. Our EHR integration and Epic answer pages go into more detail.
Who has to sign a business associate agreement?
Every vendor that creates, receives, stores or sends patient data on your clinic's behalf. In an RPM program that chain is longer than people expect: the device maker's cloud, the messaging service, the hosting provider, the AI provider if one is used, and us. If a device maker won't sign a BAA for its developer API, that device's data path has to change.
We list the chain in the Blueprint with each vendor's BAA status, encrypt readings in transit and at rest, and keep an audit trail of who saw which patient's data and when.
Is RPM software a regulated medical device?
It can be. Software that only moves, stores and displays device data is treated differently by the FDA from software that analyses readings to drive a treatment decision. Simple limits set by a clinician sit on one side. A model that predicts deterioration may sit on the other. We design so the line is clear and written down, and our answer page on regulated medical devices explains where the FDA draws it.
We don't make device clearance claims. If your product needs a regulatory review, you'll know before the build, and it goes to your regulatory adviser.
What have we built that looks like this?
TrialTriage, an oncology platform we built, ranks clinical trials for each patient and routes every match through a nurse before it counts. It was built HIPAA-aligned with full audit trails, which is the same nurse-signs-off pattern an RPM alert queue needs.
TankAware is not clinical. It's an AI and IoT platform for petroleum sites, where sensors stream real-time tank data and predictive alerts flag problems before they become failures. We name it because the engineering is the same: device data in, thresholds, alerts a person acts on, across hundreds of sites.
Nurse review and sensor alerts we have shipped
What does the first step look like?
Start with a 45-minute call with an engineer. Bring your device list, your EHR and your current alert protocol. The next step is a fixed-fee Blueprint, credited in full against the build: the data path, the BAA chain, what your EHR will accept and a fixed price per milestone. If the plan isn't one you'd act on, you don't pay for it.
Questions clinics ask about RPM software
01Who builds remote patient monitoring software for clinics?+
Hashlogics builds remote patient monitoring software for clinics and home care agencies. It collects readings from connected devices, alerts a nurse when a threshold is crossed, and files the record into Epic, athenahealth, eClinicalWorks or the EHR you run. Every alert is closed by a person, with the time logged.
02Can RPM readings go straight into our EHR?+
Often, but it depends on your EHR and its setup. Some accept readings as discrete observations through FHIR R4; others take only a summary document. Where neither is open, a staff queue files them. We confirm which applies in the Blueprint, before the build.
03Who reviews alerts at night?+
Your protocol decides. Some clinics keep a nurse on call, and the software escalates to them; others run RPM as a daytime service and tell patients to call 911 in an emergency. The software follows the rule you write and logs every hand-off.
04What documentation does RPM billing need?+
Patient consent, a practitioner's order, the device used, the days readings arrived in each 30-day period, and staff minutes with notes of each patient contact. CMS revised its thresholds for 2026, so we check the current fee schedule with your billing lead. The software counts days and minutes as they happen.
05Is RPM software a regulated medical device?+
It can be. Software that only moves and shows device data is treated differently from software that analyses readings to drive treatment. We make the line explicit in the design, and your regulatory adviser makes the call. We don't make clearance claims.
Go deeper
- Healthcare hub →Everything we build for clinics and care providers.
- Telemedicine app development →Scheduling, licensure and records around the video call.
- Home care software →Scheduling, visit records and compliance for home care agencies.
- EHR integration →What Epic, athenahealth and eClinicalWorks let a third party read and write.
- Epic integration: what a real build involves →Access, sandbox, FHIR and the parts that take longest.
- When does my software become a regulated medical device? →Where the FDA draws the line for health software.
