Remote patient monitoring

Your devices work. Your write-back doesn't.

RPM platforms live or die on whether observations land cleanly in the chart, with the right provenance, in front of the right care team, on the hospital's terms. SoFaaS™ is the runtime that takes that problem off your plate so your product ships into more hospitals, faster.

The shape of a stuck RPM deal

The clinical case is obvious. The pilot data is good. The hospital wants the program. Then it hits the wall: no standardized FHIR write-back pattern, no clean answer to alert-routing inside Epic, no SOC 2 evidence the security team will accept, and no Showroom listing.

Each one is a months-long workstream. Together, they're the reason most RPM vendors are stuck running pilots instead of system-wide programs.

What hospital security actually asks RPM vendors

  • Where do device observations live before they hit the chart, and for how long?
  • What FHIR resources do you write, with what provenance, and at what cadence?
  • Which clinician sees an out-of-range alert, and what's the escalation path inside our workflow?
  • How do you isolate our hospital's patient data from your other customers' patient data?
  • Show me your SOC 2 Type II report, your BAA, and your sub-processor list.

What SoFaaS™ handles for you

FHIR Observation write-back

Provenance, units, status — the chart write the hospital can defend in review.

Device + sub-processor posture

Your device cloud documented as a sub-processor in the standard SoFaaS™ evidence packet.

SMART App Launch

Care-team views launch in-context inside Epic with patient and encounter binding.

Multi-tenant isolation

Per-hospital data partitioning baked into the runtime. Same answer in every questionnaire.

SOC 2 Type II + BAA

Annual audit, full report shareable under NDA the same week procurement asks.

Showroom listing

Submission and ongoing maintenance handled. Distribution open by the time you're cleared.

The first hospital is hard. The tenth is harder.

The first hospital teaches you what RPM review actually looks like — alert routing, chart-write provenance, device attestation. It's slow, but it's finite.

The tenth hospital is what kills internal-build RPM platforms. Each hospital wants its own SSO, its own audit format, its own EHR version, its own escalation workflow. Without a runtime that absorbs that variance as configuration, every hospital becomes another integration project.

SoFaaS™ sits between your RPM product and the long tail of hospital-specific requirements. You ship the same app; we make it deployable into every hospital that asks.

FAQ

Why does RPM stall in hospital review?

RPM platforms write a continuous stream of observations into the chart from devices the hospital didn't issue and didn't validate. That triggers the longest version of every security and clinical-safety review hospitals run — data provenance, device attestation, write-back volume, alert routing, and escalation workflow. Each one of those is a separate workstream the hospital wants documented before they say yes.

What does SoFaaS™ handle for an RPM vendor?

SMART App Launch into the care-team workflow, FHIR Observation and Device write-back with full provenance, audit logs the hospital can ingest, multi-tenant isolation per hospital, the SOC 2 Type II + BAA posture, and the Epic Showroom listing. You keep the device pipeline, the algorithms, the patient-facing app, and the care model — the parts that make your product yours.

How is this different from a Redox-style integration pipe?

Redox moves data between systems. SoFaaS™ is the runtime your app actually runs on — the hosting, the auth, the listing, the compliance posture, and the per-hospital configuration. We complement integration platforms; we don't replace them. RPM vendors usually need both layers, and we make the second one disappear.

What about device data residency and FDA considerations?

Device-level FDA posture stays with you — that's part of the IP we don't touch. SoFaaS™ handles the hospital-side data residency, BAA, and documentation hospitals expect for the FHIR resources we write on your behalf. We treat your device cloud as a documented sub-processor in the standard SoFaaS™ posture.

How does this scale past the first hospital?

The first hospital teaches us their specific RPM review questions; we hard-code the answer into the standard SoFaaS™ evidence packet. By the third or fourth hospital in the same category, the review converges on the same artifacts and the timeline collapses from quarters to weeks.

Have a deal stuck on Epic?

Tell us about it. Half-hour call. We'll know within 15 minutes whether SoFaaS™ can unblock you.

Talk to us