“Does it integrate with our EHR?”
It is one of the first questions organizations ask when evaluating a remote patient monitoring platform. It is also too broad to produce a useful answer.
An integration may mean a link that opens another application. It may mean a document uploaded to the chart. It may mean readings written to a flowsheet. It may also include patient enrollment, task routing, documentation, and status updates moving between systems.
Those experiences are operationally very different. Before treating “EHR integration” as a checked box, ask what the integration will allow your team to do.
1. How Are Patients Matched Between Systems?
Every downstream workflow depends on associating the information with the correct patient.
Ask which identifiers are used, what happens when demographic information does not match, and how duplicate or rejected records are handled. Determine who is responsible for resolving exceptions and whether the team can see those exceptions before they affect care.
A successful API call is not useful if the information cannot be reliably connected to the correct record.
2. What Information Moves in Each Direction?
“Bidirectional” is helpful language, but it still does not explain what moves.
Create a specific list:
Can patient demographic information flow into the RPM platform?
Can enrollment status be written back?
Are individual readings, trends, summaries, or all three available?
Can device information be viewed?
Can completed outreach be documented in the EHR?
Can orders or program status changes be communicated back to the RPM system?
ONC distinguishes between APIs that read EHR data, write information to the EHR, and provide access to non-EHR information. Its research also shows that organizations use a mix of standards-based APIs and other methods to support these capabilities.
The practical lesson: “API available” does not describe the workflow.
3. Where Does the Work Appear?
Determine where staff will spend their day.
Will RPM work appear in an existing EHR inbox or task queue? Will staff need to open the RPM platform? Does the integration support contextual launching into the correct patient record? Will nurses, care managers, providers, and billing staff use the same view?
The right answer does not have to be “everything happens in the EHR.” However, it does need to be intentional.
A specialized RPM workspace may make monitoring more efficient, while the EHR remains the system of record. Problems arise when teams must repeatedly compare systems without a clear source of truth.
4. Does the Integration Create Action or Just Display Data?
A high reading is not the same as an assigned intervention. For every event that may require attention, ask:
What creates a task?
Who receives it?
What determines priority?
How quickly should it be completed?
Can it be reassigned?
What happens when it becomes overdue?
How does the team know it was resolved?
FHIR’s Task resource is specifically designed to represent work and track it through states such as assigned, in progress, completed, or failed. That model reinforces an important operational principle: information and responsibility must both be managed.
5. How Are Exceptions Handled?
Most integration demonstrations show the ideal path. Your evaluation should focus equally on what happens when:
A patient record cannot be matched
A device has not transmitted
A reading arrives without an expected unit
The EHR is temporarily unavailable
A staff member is out of office
An alert occurs after hours
Documentation fails to write back
A patient cannot be reached
Ask whether failed transactions are visible, who receives them, and how they are retried or resolved. If the exception path is simply “someone will notice,” the program still depends on manual surveillance.
6. What Is Documented—and Where?
Define which system holds the official record of:
Patient consent and enrollment
Device setup and education
Readings and trends
Time spent on treatment management
Patient communication
Clinical decisions
Escalations
Program discharge
CMS identifies education and setup, device supply, and treatment management as distinct parts of RPM. Your documentation design should make it possible to understand how those parts occurred without reconstructing the month from memory.
Billing requirements should be validated with your billing, compliance, and legal teams rather than assumed from the presence of an integration.
7. Can You Measure the Workflow?
A mature integration should help answer operational questions. Can you report on:
Unresolved alerts
Time to first review
Time to patient contact
Overdue tasks
Patients with missing readings
Failed data transfers
Staff workload
Escalation volume
Enrollment and disengagement trends
Impilo’s approach is to connect the operational layers surrounding RPM, including device logistics, engagement, monitoring, and data exchange. EHR integrations and APIs should support the way a care team works rather than forcing every organization into the same operating model. EHR integrations include Elation, Healthie, athenahealth, CCIQ, eClinical Works, and more.
Conclusion
Do not ask only whether an RPM platform integrates with your EHR. Ask whether the integration supports your patients, staffing model, escalation rules, documentation requirements, and reporting needs.
A demo can prove that data moves. A workflow test proves whether your program can run.
Frequently Asked Questions
Q: What is the most important RPM-EHR integration capability? There is no single capability that fits every organization. However, reliable patient matching, clear task ownership, exception management, and consistent documentation are foundational to most RPM workflows.
Q: Should RPM staff work entirely inside the EHR? Not always. A dedicated RPM workspace may provide better tools for monitoring populations and managing devices, while the EHR remains the clinical system of record. The important issue is eliminating unnecessary duplication and clearly defining where each action occurs.
Q: How should an organization test an integration? Use realistic scenarios rather than a feature checklist. Test an abnormal reading, missing readings, an unreachable patient, an after-hours event, a failed write-back, and a patient discharge from the program.
