Remote Patient Monitoring Framework

The framework ships pre-integrated with common Bluetooth LE and cellular vital-sign devices, including blood pressure cuffs, pulse oximeters, glucometers and weight scales, and it has been validated against live devices of both connection types. Bluetooth LE devices are paired through guided pairing flows, while cellular devices send readings through gateway ingestion. In both cases a streaming pipeline normalizes readings from different vendors into a single FHIR-aligned data model, with Observation, Device and DeviceMetric resources, so downstream features such as alerting and dashboards do not need to know which vendor produced a reading. Device inventory, patient assignment and replacement and return workflows are handled as part of onboarding. If you work with a vendor that is not already integrated, new vendors are added through the same configuration and mapping layer used for existing devices, without touching the core engine. That matters because it keeps the stable, validated part of the framework stable: adding a device is a mapping exercise, not a re-engineering of the pipeline. API access is also available for new device vendors and cohorts if you want your own team to extend the framework. Which devices you plan to use, and how many different vendors you expect to support, should be discussed at the Fit Assessment so that device mapping can be scoped and then tested during sandbox validation before go-live.

Yes. Thresholds are configurable per vital sign, per cohort and per individual patient, so alerting can reflect the clinical reality of each group rather than a single global limit. A post-surgical cohort and a chronic hypertension cohort, for example, can run different rules on the same engine. The recovery patient may need tight attention to a short-term change, while the hypertension patient may need an alert only when a pattern emerges over days. The rules are not limited to simple above-or-below limits. The framework supports trend-based alerts, which look at how readings are moving over time, and missed-reading alerts, which flag when an expected reading has not arrived, an important signal for adherence since a patient who stops measuring can be at greater risk than one whose numbers look slightly high. These are configured without touching the underlying rules engine, so clinical teams and implementation staff can tune alerting as programs evolve instead of waiting for engineering changes. Thoughtful thresholds also protect your clinicians from alert fatigue: limits that are right for the cohort mean flagged patients really are the ones who need attention, and the worklist-style care team dashboards place them first. Your cohorts and the rules each one needs are mapped during the Fit Assessment and configured and tested before go-live, and clinical teams remain responsible for deciding which thresholds are appropriate for their patients.

The framework captures the information that RPM billing depends on, as the work happens, and makes it exportable to your billing workflow. It does not submit claims on your behalf. RPM reimbursement relies on being able to show device setup and the time spent by clinicians reviewing patient data, and in many programs that evidence is reconstructed afterwards, which is time-consuming and creates room for error. Here, billing code mapping for CPT 99453, 99454, 99457 and 99458 is built into the same data layer that logs device readings. Device-setup activity and clinician-review minutes are recorded automatically against those codes as monitoring and review take place, so time-in-monitoring and review time are not something staff have to track separately. The captured data can then be exported into whatever billing process you already use. That division of responsibility is intentional. The framework is accurate about what happened, and your billing team keeps control of the final coding decisions, payer rules and claim submission. Because the data originates from actual monitoring and review activity, it also gives you a clearer view of how much clinician time each program consumes. How the export should be structured and how your billing team will review it is scoped during the Fit Assessment, and you can check the output end to end during sandbox validation, before any real patient data is involved.

Data reaches your EHR through the framework's configuration and mapping layer. That layer takes incoming device readings and outgoing alerts and routes them into your EHR using FHIR Observation resources, or through an HL7 bridge where that is what your EHR expects. Not all EHRs accept data in the same way, which is why the integration is a configuration step rather than a fixed connection: the same framework can be mapped to an EHR with a modern FHIR interface or to one that still depends on HL7 v2 messaging. Inside the framework, readings from all device vendors are first normalized into a single FHIR-aligned data model, with Observation, Device and DeviceMetric resources, so the EHR receives consistent, structured data whichever device produced it. The aim is that vitals and alerts appear within the clinical workflow your teams already follow, rather than in a separate system that clinicians must remember to open. The framework fits into your existing process rather than replacing it. The mapping is set up during the second step of the deployment path, where your EHR connection is configured, and then tested during sandbox validation, where you can run readings end to end against your EHR sandbox and confirm how the data behaves in your own environment before go-live. The exact approach for your EHR, FHIR or HL7 bridge, is confirmed during the Fit Assessment.

Yes. Remote Patient Monitoring and Care Management share a common data model, so they are designed to be used together without a custom integration between them. When both are deployed, RPM readings feed directly into Care Management's risk stratification and task orchestration, and no patient records are duplicated. That has practical consequences for the care team. A monitored patient's readings can influence how that patient is prioritized, since HCC-based risk scoring helps the team see who needs attention first, and an RPM alert can create a task inside the patient's care pathway with a due date, an owner and escalation rules, instead of sitting as a notification in one system that someone has to notice and copy into another. Because everyone works from the same patient record, nurses, coordinators and physicians can see both the monitoring picture and the care plan in one place. The two frameworks also bring complementary billing support, with RPM covering CPT 99453–99458 and Care Management covering CCM and TCM time-based codes, both captured from actual activity. Each framework is white-labeled and configurable, HIPAA-compliant and BAA-ready, and hosted in your cloud or by Emorphis Health. If you are considering both, mention it at the Fit Assessment so that device mapping, alert thresholds, care pathways and task rules can be planned together and then tested together during sandbox validation.