If you are evaluating remote patient monitoring software, you will see the phrase “SMART on FHIR” everywhere. Here is what it actually means and why it should be near the top of your requirements list.
FHIR, in one paragraph
FHIR (Fast Healthcare Interoperability Resources) is the modern standard for exchanging healthcare data. It defines common building blocks – Patient, Observation, Condition, and so on – and a web API for reading and writing them. Certified EHRs in the United States are required to expose FHIR APIs under the 21st Century Cures Act.
What SMART adds
SMART (Substitutable Medical Applications, Reusable Technologies) is the app-launch and authorization layer on top of FHIR. It lets an application launch inside the EHR with the current patient’s context, and it uses OAuth 2.0 so the health system controls exactly what data the app can access. Think of it as the app store model for the EHR.
Why this matters for RPM specifically
- Adoption. The number one killer of RPM programs is a separate portal nobody opens. A SMART app lives inside the chart where clinicians already are.
- Data quality. Device readings written back as FHIR Observations become part of the longitudinal record – trendable, referrable, auditable.
- No rip-and-replace. The same SMART app pattern works across FHIR-enabled EHRs, so switching or adding EHRs does not restart your RPM program.
- Security posture. Scoped OAuth access is far easier for your compliance team to approve than credential-sharing or custom interfaces.
Questions to ask any RPM vendor
- Does your app launch inside the EHR via SMART on FHIR, or is it a standalone portal?
- Do device readings write back to the chart as structured data?
- Which FHIR scopes do you request, and why?
- How is billing documentation surfaced to the care team?
SimplyRPM answers all four the way you would hope. See how our integration works.
Leave a Reply